能把成都加上么~

这怕是属于 OLAP 的 SQL 了吧。。

还在 MySQL DBA 不？

有这个可能性。
我觉得更应该去查下 pg 的 CPU 高的原因。

@Wisho 表述有点问题，应该是合称

@Wisho 你说的这种场景这么说是讲的通的。
比如这个场景:
session 1:update ttt set gap=100 where gap<=3;
（我觉得这点 MySQL 处理的有点粗暴，直接在底层 B+ 树上锁住区间）

活着就是吃好，喝好，耍好，父母子女健康。

补充一下：Next-key lock 是前开后闭区间。

首先：Next-key locking 是 gap lock 和 record lock 的统称，解决幻读问题是用 gap lock 来解决的。
Q:“为什么这种 next-key locking 能解决幻读问题: 就是说　 select * from `ttt` where `gap`=3 for update; 锁定了[1,5] 范围，假如他降级为行锁（就是辅助索引只锁 3，聚集索引还是会锁 11113 ）会出现什么幻读问题？”
A:那如果此时再插入一条 gap=3 的记录，那就出现幻读了。

你这表达和排版，看起来脑壳痛。

冲鸭

冲鸭冲鸭冲鸭

冲鸭冲鸭

冲鸭

分母

内网路由器 DNS 劫持

add index idx_id_createtime(id,create_time)