回

没用

m9m 在用两年，平时放一台 27 寸显示器+mbp ，和其他若干小东西。618 750 入的，普通敲键盘时，晃动完全能接受，确认可以入手

分析实际使用场景，实时性要求很高，用 1 ；否则 2
1 、干掉本地缓存，只用远端缓存
2 、保留本地缓存，本地缓存设置很小的过期时间，1 秒？从本地缓存读数据，过期的话读远端再写本地

不管自学还是培训，完事后赶紧找个带互联网性质的公司（忽略公司大小，先入职），待段时间你就知道了这个行业大家都在用什么，应该学什么，然后重新梳理你需要学习的技能树，然后找资料自学，过程中准备提升学历，最后看情况，要不要跳到适合的好点的正儿八经的互联网公司。
BTW ，认真考虑下是否需要选 Java ，真的太卷了，举个例子，一两年甚至校招，Redis 、MySQL 、消息队列八股文必须熟才有资格往下继续面，用不用得上不重要，你得知道……可以考虑下往 GO 方向卷

16 256 m1 ，教育优惠，8k 多点，早买早享受

带薪学习……

--(xx, 1123424214]这个回退化成间隙锁(xx, 1123424214)

个人理解：
1.s1 事务未提交，因为间隙锁，事务 2 执行 s2 阻塞，正确
2.s1 select 添加悲观锁（ x/s ），命中覆盖索引 publish_id ，加锁范围(xx, 1123424214]，下一个锁范围是(1123424214, xxx]，继续向右遍历加 next-key lock ，因为最右值 xxx 不等于 1123424214 ，这个锁回退化成间隙锁(1123424214,xxx)；加锁结束后，事务 2 执行 s2 ，inset 时，publish_id= 1123424214 不在锁范围，所以写入成功，正确

其实还有个问题，一个月 100w 数据，单靠这种方式去统计，数据量大了一定会有问题。考虑下增量方式处理，先确定好最终需要的统计结果模型，然后建立以天（或其他粒度）维度的新表记录；新表订阅原表的 DML 操作（业务代码），异步更新新表，最后统计、展示时只需要查新表就 OK 了

1.show index from t; 看下每个索引对应的统计行数 Cardinality
2.建立联合索引(index_company_id_time_domin_id)，company 和 time 哪个放左边，取决于谁的 Cardinality 大（统计数不太准确，domin_id 如果只是 in 操作使用的话，也可以不用放到联合索引，因为 5.6 有个”索引下推“技术能解决筛选问题）
3.select timestrap, bps 这两个字段都不存在索引，所以每行记录都会回表——建议直接 select id ，然后再通过 ids 去查 timestrap, bps ，减少回表次数
----一个月 100 万数据，总表应该很大 rows 了，重新建立索引是个比较麻烦的事
----能联合索引就联合索引，别搞这么多单字段普通索引——都是坑

歪个楼，API 注释大家一般会维护更新吗？我这边也没有个统一的规定，swagger 、yapi 、wiki 接口文档各种使用吧。至于注释 param 、return 这些很少维护了

sql 中涉及查询时 a 三个字段，b 两个，b 小表，作为驱动表

1 left 不能决定会用左表作为驱动表，驱动表是小表，在决定哪个表做驱动表的时候，应该是两个表按照各自的条件过滤，过滤完成之后，计算参与 join 的各个字段的总数据量，数据量小的那个表，就是“小表”，应该作为驱动表
2 如果有 left 语义，应该将被驱动表字段放在 on ，不要放在 where

真不错

还能上车吗

硅谷？

@coderluan 所以保证手里有合同（可以通过官网、微信）下载，然后和房东好好协商沟通呗，千万别遇上那种和稀泥、让租客搬走的执法

一颗橙子，橙序员节