看起来不错，Star 了

用 force index 强制使用 city_id 那个索引

SELECT * FROM `user_info` FORCE INDEX(idx_city_id) WHERE ( `city_id` IN (45757,45967,46044,46126,46288,46473,46642,46769,46919,47078,47119,45758,45762,45786,45811,45822,45839,45850,45870,45877,45892,45905) ) AND `user_info`.`delete_time` IS NULL ORDER BY `id` DESC

把 idx_city_id 换成你实际的 city_id 那个索引的名字

常见大品牌基本可以同城，我用货拉拉从北京搬到青岛

除非完全没有编程基础，否则学习一门新语言时最好买本书从基本语法入手。

建议楼主读一下 《 ES6 标准入门》

很久没用 Java 了，是 mat 已经过时了么？为什么没人提到这个呢？我印象中分析内存泄漏的话 mat 比 jprofiler 方便。

@lurenw @fortunezhang 楼主原 SQL 中就是 left join，是允许 b 表里不存在的。

如果你前后 SQL 里的 b.time 都是打错了，应该是 a.time 的话，那么拆开写完全没问题。甚至很多大厂的规范中会要求必须拆开写，理由如 #3 所讲，即使未来 a 表和 b 表拆到两个库中，SQL 都不用改。

还是 MBP 吧，用起来省心。
另外，鉴于楼主是搞运维的，建议买回来后先重做一下系统，把文件系统搞成区分大小写的。

楼上某些脱离场景谈规范的都是耍流氓。凡事无绝对，“代码里不能使用中文”这条并不适用于所有场景。
这段代码从格式上来看还是比较工整的，用中文变量名之前相信也是尝试过用英文的，实在太蛋疼了才用的中文。

以存储一个超大文本文件来举例：
存储时不做任何压缩，虽然耗费的存储空间会比较大，但会达到比较快的读写速度，这就是空间换时间。
把文件压缩存储，这样读写时需要额外做一步解压或者压缩，读写速度肯定不如直接读写，但是会省很多磁盘空间，这就是时间换空间。

为什么要查剩余值？如果只是为了确保够扣的话，只要加在扣除的 where 语句里就可以了，不需要用事务去锁表：
UPDATE package SET current = current - ${VALUE} WHERE current >= ${VALUE} AND expire > NOW();

也可以用 REDIS 来做，key 的值为 current, 过期时间为 expire，每次请求来了直接去 decr，如果返回的结果是小于 0 的，就说明原来的余量是不够扣的，把刚才扣的值 incr 回去，当作是没扣过，然后返回一个扣失败。如果过期的话，decr 的结果一定是小于 0 的，也是扣失败。

数据库用户名密码存储在配置中心（比如阿里开源的 Nacos ），写个 Listener 监听配置变化重建数据库连接。

不需要调接口，libphonenumber 就可以验证，前端可以用 libphonenumber-js

肯定是招一个 P7 呀
1. 工作效率： 个人经验，P7 的产出效率在 P5 的 2 倍以上；
2. 产出质量：P7 的无论是架构能力还是代码质量绝对是比 P5 要强的；
3. 沟通成本： 不用多说了。

跳槽时建议把期望薪资放在涨幅 30% 以内，否则很容易谈崩。
当然，也有特殊情况是能达到更高幅度涨薪的，但 90%以上的跳槽都不属于那些特殊情况。

大公司有很多个主体很正常的，各种各样原因都有，甚至有可能同期入职同一个部门的都会签不同主体。