还在 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)

@lihongjie0209
这个 autoinc_lock 可以通过 innodb_autoinc_lock_mode=2 参数 设置来避免，当然这样会导致自增不连续。
但是 uuid 导致的随机 IO 更有可能是并发效率降低。

32， 没积蓄， 有房贷，今年又增加了车贷，关键是车的首付还是刷信用卡套出来的。每个月房贷+车贷+装修贷，压力大的一笔，而且下个月娃也要出来了。日常靠信用卡活着。

@acr0ss 你确定并发 uuid 还快？