INSERT被Gap锁阻塞的直接原因是插入前需申请插入意向锁，而该锁与已存在的Gap/Next-Key锁不兼容。
INSERT 被 Gap 锁阻塞的直接原因
不是 INSERT 本身加了 Gap 锁，而是它在插入前要申请「插入意向锁（Insert Intention Lock）」，而这个锁和已存在的 Gap 锁/Next-Key 锁不兼容。InnoDB 在 RR 隔离级别下，只要目标插入位置落在某个活跃事务持有的 Gap 或 Next-Key 锁范围内，就会等待——哪怕那块间隙当前空无一物。
典型触发链：SELECT ... FOR UPDATE 或 UPDATE ... WHERE range_cond 先锁住一段索引区间 → 后续 INSERT 恰好想插进这个区间 → 被卡住或报 Lock wait timeout exceeded。
- 空表最危险：
SELECT * FROM t WHERE id = 5 FOR UPDATE会锁住(-∞, +∞)整个主键空间 - 非唯一索引上范围查询后插入，比主键插入更容易中招
-
INSERT ... SELECT或带子查询的插入，可能绕过等值优化，意外触发 Gap 锁
为什么并发 INSERT 会死锁：插入意向锁的兼容性陷阱
插入意向锁本质是 Gap 锁的一种特殊形式，但它有自己的一套兼容规则：多个事务可以同时对同一间隙加插入意向锁（理论上兼容），但实际执行时，InnoDB 的锁队列调度机制会让它们排队等待。当两个事务几乎同时尝试插入空表或同一稀疏区间时，就容易形成 A 等 B、B 等 A 的循环等待。
常见死锁日志里能看到类似线索：
TRANSACTION 12345, ACTIVE 0 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s) INSERT INTO t VALUES (1, 'a')
关键点：
- 死锁只发生在 RR 隔离级别；RC 下 Gap 锁基本不生效，INSERT 不会因此死锁
- 即使表有主键，只要没走索引（如 WHERE 条件没命中索引），InnoDB 可能退化为全表扫描 + 大范围 Gap 锁
- 自增 ID 跳号（如插入成功 id=1，重试后 id=3）是空表并发插入死锁的典型副产物
怎么快速定位是哪个 Gap 锁在拦路
别猜，查 performance_schema.data_locks。MySQL 8.0+ 已废弃 INNODB_LOCKS，必须用这个视图。
先找出被阻塞的事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'LOCK WAIT';
再关联锁等待关系：
SELECT * FROM performance_schema.data_locks WHERE ENGINE = 'INNODB' AND LOCK_TRX_ID IN ( SELECT BLOCKING_TRX_ID FROM information_schema.INNODB_LOCK_WAITS );
重点关注：
-
LOCK_MODE是X,GAP或X,NEXT-KEY -
LOCK_DATA显示具体间隙边界，比如supremum pseudo-record（空表全锁）、5（表示(-,5)）、5, 10（表示(5,10)） -
INDEX_NAME告诉你锁在哪条索引上，结合业务 SQL 判断是否合理
绕过 Gap 锁阻塞的实操策略
不是关锁，而是收窄锁范围或调整行为。
- 临时降级隔离级别：在会话级执行
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，可让普通 INSERT 脱离 Gap 锁干扰（但需确认业务能否容忍幻读） - 确保插入字段有高效索引：特别是
INSERT ... ON DUPLICATE KEY UPDATE或带WHERE子句的插入，索引缺失会导致锁扩大 - 拆分长事务：把
SELECT FOR UPDATE尽量靠近后续INSERT/UPDATE，避免提前加锁后长时间空转 - 避免空表高并发直插：可预插一条哨兵记录（如
id = 0），让间隙变为(-∞, 0)和(0, +∞)，缩小单个 Gap 锁覆盖范围
Gap 锁的“不可见性”是最容易被忽略的——它不锁任何真实数据，却实实在在拦住所有插入。排查时盯着 LOCK_DATA 和 INDEX_NAME 比看 SQL 更有效。
