Next-Key Lock 会阻塞 INSERT 是因为插入意向锁与已有的 NEXT-KEY 或 GAP 锁不兼容；只要插入位置落在被锁区间内（即使为空），就必须等待。
Next-Key Lock 为什么会让 INSERT 卡住
根本原因不是 INSERT 自己加了锁，而是它要申请 插入意向锁，而这个锁和已存在的 NEXT-KEY 或 GAP 锁不兼容。InnoDB 规定：只要你要插的位置落在别人已锁的区间里，哪怕那块空着，也得等。
比如事务 A 执行了 SELECT * FROM t WHERE id > 10 FOR UPDATE，InnoDB 就可能锁住 (10, 15] 和 (15, +∞)；这时事务 B 想 INSERT INTO t (id) VALUES (12)，虽然表里没有 id=12 的行，但 12 落在 (10, 15] 内，就会被阻塞。
-
LOCK_DATA显示的是间隙边界（如10, 15），不是你 INSERT 的值本身 - 空表最危险：
SELECT ... WHERE id = 5 FOR UPDATE会锁(-∞, +∞)整个主键空间 - 非唯一索引上范围查询后紧跟 INSERT，比主键插入更容易中招
怎么确认是不是 Next-Key Lock 在拦路
别猜日志，直接查系统表：
先看谁在等：SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'LOCK WAIT'
拿到 TRX_ID 后查锁详情：SELECT * FROM performance_schema.data_locks WHERE LOCK_TRX_ID = 'xxx'
重点关注：
-
LOCK_MODE是GAP或NEXT-KEY -
LOCK_DATA显示开区间，如5, 10表示(5, 10)已被占 -
LOCK_DATA为NULL或空值 → 很可能是全表扫描导致的隐式间隙锁，说明缺索引
哪些 INSERT 容易触发 Next-Key Lock 阻塞
不是所有 INSERT 都会惹上这事，关键看它是否“被迫扫范围”：
-
INSERT ... SELECT：源表扫描加 Next-Key Lock，尤其 WHERE 没走索引时≈锁表 - 目标表没主键或合适索引：InnoDB 用隐式聚簇索引，间隙锁覆盖整个范围
- 非唯一二级索引字段上做范围查询（如
WHERE status = 'pending'）后立刻INSERT，新数据容易掉进已被锁住的区间 -
ON DUPLICATE KEY UPDATE：先按唯一索引做一次SELECT FOR UPDATE级查找，锁已持，再决定插还是更
绕过阻塞的实操要点
核心是让 InnoDB 尽量只加记录锁，少扫间隙：
- 给常用查询条件建联合索引（如
(status, create_time)），比单列索引锁得更准 - 避免在非唯一索引字段上范围查询后直接插入；可拆成两步：先用唯一索引查出 ID，再
INSERT ... WHERE id = ? - 若业务允许，临时降级隔离级别到
READ COMMITTED—— 但必须验证binlog_format = ROW，且注意 UNIQUE KEY 仍可能触发间隙锁 - UUID 类插入慎用批量并发：随机值让锁分散在多个页，缓冲池压力大；低数据量表建议有序单条提交
真正麻烦的不是 Next-Key Lock 存在，而是它不报错、不提示具体锁区间，只让 INSERT 卡住或报 Lock wait timeout exceeded；LOCK_DATA 显示的边界值，往往不是你 INSERT 的值，而是相邻记录构成的开区间端点。
