小时候上来就对着水龙头顿顿顿，现在长大了，讲究了，白开水了

喝应该是可以喝的

@TwoDogSon 天猫一个 to B 搬砖岗

@overthemoon 昂，自我介绍，介绍下你公司是干嘛的，然后让你自己挑一个你公司的场景说说，或者他在简历里挑一个你写的经验说说，顺着你说的展开，一个小时基本是

我看完感觉你是闲鱼，不一定是咸鱼，不妨准备一波面试？

我是普二本科，今年也正好三年，在一家后端只有 5 个人的公司干了近三年，三年基本 9 8 5 的搬砖，我也焦虑过自己工资远低于市场平均，但感觉自己一直在搬砖没太多时间去研究过太多深度

这不最近试了下大厂，结果不就成了嘛

我感觉你平时比较闲，闲到你想考公，是很多程序员羡慕的吧。但是你没把这个比我们多的时间用来提升自己的技术深度，实属可惜。

在提升自己或者说是准备面试上给你个建议：
优先准备自己工作相关的技能深度。
优先准备自己工作相关的技能深度。
优先准备自己工作相关的技能深度。

比如算法这块，我觉得你完全没必要死刷题，面搬砖岗的话，就三年的工作经验，不会怎么考太难的算法。但你肯定要搞清楚 归并排序，插入排序，快速排序，因为这是 jdk 里 sort api 实现里用到的。
面试面的不是别人会的那些东西，也不是别人写的那些面经，都是从你的业务相关技术开始或者你简历里突出写的那些技术。

焦虑的时候还是要多行动，脑子和内心活动的再频繁也还是空的，只会劳心智

淦，鸡血给你打完了，如果你工资还是市场平均水平，还这么闲，你焦虑个锤子啊焦虑🌚我等向往还来不及

百度，高德都有 3D 模型的 api 的，我们公司最后用了高德的，关键词 webgl

个人用的服务器，资金安全？服务器里存了自己的各种账号密码？🤔

@amiwrong123
关于覆盖索引优化服务性能
我觉得这算是后端开发做复杂列表时在 mysql 上必备知识点了

原理和实操都很简单。
覆盖索引的意思就是你 select 的列都在索引里，不需要回表。

你原始 sql 肯定没用上覆盖索引。因为你的 select 里的 quantity 应该不在索引里吧。你只是因为正好要关联 product 表，就贪婪的把 quantity 带了出来。

所以改写的话，应该是第一个 sql 只 select prod_id: select prod_id from orderitems where number=xxx(手机回复的，无法对着你的字段回复)
然后服务器根据你返回的这个 prod_id 查产品信息，后端经常说:服务端多次单表查询就是这个意思。

我以前一个列表对应的 sql join 了 8,9 表，然后 select 了 10+个字段，那个 sql 要 2000+ms，后来用了覆盖索引，第一次只查那一页的关键 id，只需要 200+ms，然后服务端多次单表查询，服务最后也只要 600ms 左右。

但是你问我要不要把覆盖索引当个圣经或者必须的准则，我觉得 duck 不必。小表之间的小查询直接带出来需要的字段可能只要 5ms，但是你从服务端走一遭，网络请求都要 10+ms，显然直接 select 出来更划算

@amiwrong123
1. 改写后的 sql 具有了去重功能: 对于我想说的去重你理解歪了。
我想说的是你 where 里的子查询虽然没有去重，可能会查出产品 id 是:1,2,2,3,4 这样的结果。
但是在执行外层的 select from product where prod_id in (1,2,2,3,4)时，id=2 的纪录只会返回一条，所以说是去重了

首先要说明的是: 你这两条 sql 是不等价的。

原始 sql 是通过 join 的形式，join 的形式最大的特点是结果集无法去重，所以当你订单里有两个产品 A 时，返回的结果集里就有两条 A 的纪录

改写后的 sql 是通过子查询的形式，这样做最大的特点是产品信息的去重，即使订单里有两个商品 A，返回的结果里也只有一条 A 的纪录。
where 里的子查询没什么问题，用的时候注意 子查询返回结果过多，可能会导致外层查询不走索引。

select 里的子查询我是坚决反对的，因为我的理解中，select 里的子查询是对每一条返回的纪录再单独执行一条 sql 。假设你订单里有 10 个不同商品，最后你要执行的 sql 数量就是 1 条主的+10 条 select 里的子查询。10 条 select 就是 10 次 io 啊…

所以就单看你这个需求，原始 sql 是一般的做法吧，不会想着花里胡哨改写。

如果非要优化性能的话，我推荐把 sql 拆成多次执行用上覆盖索引。第一次带上查询条件，用上覆盖索引，把关键的 id 返回给服务器，服务器再根据第一次返回的 id 去对应的表查附属信息。

如果理解上有错，还请大家批评指正。

升本转 java 这样毕业搬砖的机会相对比较多

最好还能考个 211，985 的研究生，这样才从本质上让自己有接触好机会的平台。

让我想起了大学选修 oracle 数据库，最后考试的时候，最后一道纯英文，心里暗骂了下老师 懒狗，肯定是从哪复制粘贴的。🤪

最简单的快速迭代方式就是，a 服务直接出相关服务，B rpc 调用。

有没有必要把相关的 dao 抽成单独模块，就看你们的划分了

不从数据库角度，从业务或者后端开发的角度简单说下我的理解：

我自己在建表时使用 varchar(N)是我们对这个字段有预期的或者业务上有限制的，比如昵称不能超过多少字符，推荐语不能超过多少字，不然页面展示效果不行..

当你一个 varchar>=5000 时，大概率上你已经对这个字段失去了可预期上的控制吧，比如爬虫存一些描述性文案，所以不如直接改成 text 不限制长度

阿里的 java 开发手册，我个人也认为他是从一个后端开发的角度总结的一套经验，比如数据不要外键，应用代码里做逻辑外键。

这得看你对数据的要求吧。

像我这种经常写 bug 的后端，要去修数据啥的。你给我整一堆外键约束，修数据 /导入数据工作量直接翻翻。

http://poi.apache.org/slideshow/how-to-shapes.html#Render

HSLF provides a way to export slides into images. You can capture slides into java.awt.Graphics2D object (or any other) and serialize it into a PNG or JPEG format. Please note, although HSLF attempts to render slides as close to PowerPoint as possible, the output may look differently from PowerPoint due to the following reasons:

- Java2D renders fonts differently vs PowerPoint. There are always some differences in the way the font glyphs are painted
- HSLF uses java.awt.font.LineBreakMeasurer to break text into lines. PowerPoint may do it in a different way.
- If a font from the presentation is not available, then the JDK default font will be used.

Current Limitations:
- Some types of shapes are not yet supported (WordArt, complex auto-shapes)
- Only Bitmap images (PNG, JPEG, DIB) can be rendered in Java

或许是真的不能支持这些复杂的妖魔鬼怪 PPT 吧。

也不能狂跳，大公司 hr 可能会因为你跳槽频繁而挂了你....

自己陌生的技术，还是推荐先看看中文的，快速了解这个技术相关的名词概念基本使用啥的....深挖某个技术的话还是慢慢啃官方原文