一次由「MySQL间隙锁」导致的并发插入死锁

MySQL间隙锁引发的并发死锁之谜
在数据库高并发场景下，MySQL的间隙锁（Gap Lock）本是为保证事务隔离性而设计的重要机制，却可能成为死锁的隐形推手。某次生产环境中，两个事务同时尝试插入相邻主键记录时意外触发死锁，最终导致业务请求堆积。这一现象背后，隐藏着InnoDB锁机制的复杂逻辑。
间隙锁的触发条件
间隙锁在可重复读（RR）隔离级别下自动生效，当执行范围查询或唯一索引插入时，InnoDB会锁定索引记录间的“空隙”。例如事务A查询`id BETWEEN 5 AND 10`，即使范围内无数据，也会锁定(5,10)区间，阻止其他事务插入id=7的记录。这种设计虽能避免幻读，却为并发插入埋下隐患。
死锁的典型场景
假设事务A先插入id=8（获取(5,10)间隙锁），事务B同时插入id=7（请求相同间隙锁）。此时事务A若需插入id=7，而事务B也尝试插入id=8，双方互相持有对方需要的锁资源，形成循环等待。InnoDB检测到这种僵局后，会强制回滚其中一个事务。
索引设计的影响
若表使用自增主键，插入操作通常不会触发间隙锁冲突。但若主键为业务字段（如订单号），并发插入非连续值时，间隙锁范围可能重叠。例如订单号按时间戳生成，密集插入时不同事务的间隙锁可能覆盖相同区间，大幅提升死锁概率。
解决方案与优化建议
降低隔离级别到读已提交（RC）可彻底禁用间隙锁，但可能引发幻读。更稳妥的方案是优化索引设计，尽量使用自增主键；或调整插入逻辑，将批量插入改为有序单条提交。监控工具如`SHOW ENGINE INNODB STATUS`可帮助定位死锁链。
这一案例揭示了锁机制与并发控制的微妙平衡。理解间隙锁的运作原理，才能在高性能与数据一致性之间找到最佳实践。