直接执行show engine innodb status\g，跳至latest detected deadlock区块，重点查看sql后lock_mode是否含“gap before rec”、lock_data是否为成对值（如1,5）、被回滚事务是否对不存在主键执行update——三者同时出现即确认间隙锁冲突。
怎么看死锁日志里是不是间隙锁在作怪
直接执行 SHOW ENGINE INNODB STATUS\G，跳到 LATEST DETECTED DEADLOCK 区块，重点盯三处：
- 每条 SQL 后面的
lock_mode X locks gap before rec—— 出现这个，基本就是间隙锁冲突；lock_mode X locks rec but not gap是纯行锁，问题通常没那么隐蔽 - 看
lock struct(s)下的lock_trx_id和lock_data：如果lock_data显示的是两个值（比如1, 5），说明锁住的是(1, 5)这个开区间，典型间隙锁行为 - 被回滚事务的 SQL 如果是
UPDATE ... WHERE id = ?且该id不存在，那它大概率正在申请间隙锁；另一方若也做类似操作（如id = 3和id = 4），就极易交叉重叠
怎么确认间隙锁范围是否重叠
间隙锁死锁的本质是“两个事务各自锁了一段本不该交叠的间隙，但实际却重合了”。验证方式不是靠猜，而是查真实加锁记录：
- 执行
SELECT * FROM performance_schema.data_locks WHERE LOCK_TYPE = 'RECORD'，过滤出当前活跃事务的锁 - 重点关注
LOCK_DATA字段：如果看到多条记录的LOCK_DATA都是1, 5或5, 9这类成对值，说明多个事务正在竞争同一间隙 - 结合
INDEX_NAME看是否走对索引——如果INDEX_NAME是PRIMARY但LOCK_DATA跨度极大（比如从100到10000），说明查询没走索引，被迫锁了整个范围
为什么 saveOrUpdate 这类 ORM 方法容易触发间隙锁死锁
像 MyBatis-Plus 的 saveOrUpdate(entity, wrapper) 这种封装，底层会先 UPDATE 再 INSERT。问题出在第一步：
- 当
WHERE条件匹配不到任何行时（例如id = 7不存在），InnoDB 会在相邻索引值之间加间隙锁，比如表里有id=6和id=9，就会锁住(6, 9) - 如果两个并发请求分别查
id=7和id=8，都落进同一个间隙(6, 9)，就会互相等待对方释放间隙锁 - 更麻烦的是，ORM 自动生成的 SQL 很少显式加
FOR UPDATE，开发者误以为“只是查一下”，其实已经持有了不可见的间隙锁
怎么改代码才能绕过间隙锁死锁
不建议关间隙锁（innodb_locks_unsafe_for_binlog=1 或降隔离级别），风险远大于收益。稳妥做法是把“试探性更新”变成“确定性操作”：
- 用主键或唯一索引做存在性判断：
SELECT id FROM t WHERE id = ? LOCK IN SHARE MODE，再根据结果决定走UPDATE还是INSERT，避免无谓的间隙锁 - 批量写入场景下，提前按主键排序，让所有事务以相同顺序访问数据，消除交叉加锁可能
- 对高频插入的业务（如订单号生成），改用自增 ID 或雪花 ID，避免在业务字段上做范围查询和间隙竞争
- 如果必须用
saveOrUpdate，确保wrapper条件始终命中索引——别用name = ?这种非唯一字段，尤其当name上没索引时
间隙锁本身不是 bug，它是 RR 隔离级别下防止幻读的必要机制。真正危险的是让多个事务在“看不见的间隙”里盲目竞争。排查时紧盯 lock_mode ... gap 和 LOCK_DATA 的具体值，比泛泛而谈“降低并发”有用得多。
