个人理解：
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 所以保证手里有合同（可以通过官网、微信）下载，然后和房东好好协商沟通呗，千万别遇上那种和稀泥、让租客搬走的执法

一颗橙子，橙序员节

AOC U2790PQU，不到 2K，很多情况下能满足你的需求了

@libook 好的

@murmur
@mingmeng
@Administrat0r
最初是按照黑苹果出的配置，后边不打算了，所以配置看着有点不对的感觉

雷了雷了

首先毕业一年通过跳槽目前拿 22 很正常（注意楼主说的，上家公司），更何况还没说学历背景；那槽点只有一个了，*全网第一*，辞职吧，这家公司不配拥有你;这是狗头

收藏，需要梯子

插眼