MySQL 5.7中间隙锁引发的死锁必须交叉比对INNODB_TRX、INNODB_LOCKS与死锁日志的索引位置及lock_mode，因INNODB_LOCK_WAITS不记录GAP锁等待链，且lock_mode含“gap before rec”实为插入意向锁或唯一键检查所需，并非业务主动加锁，需结合lock_space/lock_page/lock_rec定位物理间隙重叠。
MySQL 5.7 中间隙锁（GAP）引发的死锁，不能只看 SHOW ENGINE INNODB STATUS 里的锁类型描述，必须交叉比对 INNODB_TRX、INNODB_LOCKS 和日志中记录的索引位置与 lock_mode。
从死锁日志里识别 GAP 锁的真实含义
死锁日志中出现 lock_mode X locks gap before rec insert intention 或 lock_mode S locks gap before rec，不代表当前事务“主动加了 GAP 锁”，而是它在尝试获取记录锁（X/S）前，**必须先获取对应间隙上的插入意向锁或共享间隙锁**——这是 InnoDB 在唯一索引/主键上做 duplicate-key 检查或外键约束时强制行为。
常见误判点：
- 看到
gap before rec就认为是 RC 隔离级别配置错误（其实 RC 下对唯一索引的 duplicate-check 仍会用 GAP 锁） - 忽略
insert intention是一种特殊的 GAP 锁，它和普通 GAP 锁兼容，但和 RECORD X 锁互斥 - 日志里显示事务 “HOLDS S lock on gap”，实际是它在 INSERT … ON DUPLICATE KEY UPDATE 过程中为避免幻读而持有的检查锁，不是业务逻辑显式请求的
用 INNODB_LOCKS 确认锁的物理位置是否重叠
INNODB_LOCKS 表在 5.7 中仍可用，关键字段是 lock_trx_id、lock_mode、lock_type、lock_index、lock_space、lock_page、lock_rec。真正决定是否冲突的是后三者组成的“锁定位”。
实操建议：
- 先从死锁日志里提取两个事务等待的索引名（如
`a`）和 record 物理位置（如heapno=3），再查INNODB_LOCKS中相同lock_index+ 相同lock_space/lock_page的记录 - 若事务 A 持有
lock_mode = S+lock_type = RECORD，事务 B 等待lock_mode = X+ 同一lock_rec，说明是同一行记录的 S/X 冲突，不是 GAP 问题 - 若事务 A 持有
lock_mode = X+lock_type = RECORD，事务 B 等待lock_mode = X+lock_type = INSERT_INTENTION，且两者lock_page相同但lock_rec不同 → 典型 GAP + 插入意向锁循环等待
为什么 INNODB_LOCK_WAITS 在 GAP 场景下容易误导
INNODB_LOCK_WAITS 在 MySQL 5.7 中不记录 GAP 锁的等待链，只反映 RECORD 级别的直接阻塞。当死锁由两个事务分别持有不同记录上的 X 锁、又各自等待对方间隙上的插入意向锁时，INNODB_LOCK_WAITS 可能为空，或只显示一条单向等待，完全无法还原闭环。
此时必须：
- 用
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_state = 'LOCK WAIT'找出卡住的事务 ID - 用该 ID 去
INNODB_LOCKS查它等待的lock_trx_id（注意：这个字段不一定等于持有者 trx_id，可能为空） - 转而查
SHOW ENGINE INNODB STATUS\G的TRANSACTIONS段，搜索 “HOLDS THE LOCK(S)” 对应的 trx_id 和 lock_rec 位置，手动比对是否落在同一 gap 区间内
最易被忽略的一点：间隙范围不是靠 lock_rec 单值判断的，而是由前后两条已存在记录共同界定。比如表中已有 a=1 和 a=4，那么 a=2 和 a=3 都落在同一 gap (1,4) 内——即使两个事务锁的 heapno 不同，只要落在同一 gap，INSERT_INTENTION 就可能互斥。
