MySQL 死锁 1213 实测：读懂 LATEST DETECTED DEADLOCK，间隙锁 + 插入意向锁为什么也会死锁

会话 A：BEGIN; UPDATE accounts … WHERE id=1; 等 1 秒; UPDATE … WHERE id=2; COMMIT。会话 B 晚 0.3 秒开始，顺序反过来：先 id=2，再 id=1。这就是两笔方向相反的转账同时发生。

A 的第二条 UPDATE 在 1.0 秒时开始等 B 手里的 id=2；B 的第二条在 1.3 秒时要 A 手里的 id=1，环形成。InnoDB 没有等任何超时，当场回滚 B 并返回 ERROR 1213 (40001)，A 随即拿到锁，2.31 秒提交。两轮结果一样，最终余额 id=1 为 990、id=2 为 1010，只有 A 的转账生效。

SHOW ENGINE INNODB STATUS\G 只保留最近一次死锁；打开 innodb_print_all_deadlocks 后每一次都会写进错误日志，我在测试实例的 err.log 里也看到了同样的内容。场景一的日志我只保留了关键行：

*** (1) TRANSACTION: … UPDATE accounts SET balance=balance+10 WHERE id=2 —— 事务 1 被卡住时正在执行的语句。注意它只显示「卡住的那条」，事务前面已经执行过的 UPDATE id=1 不会出现，这是很多人读日志时漏掉的：要靠 HOLDS THE LOCK(S) 反推。

*** (1) HOLDS THE LOCK(S): … index PRIMARY of table `deadlock_lab`.`accounts` … lock_mode X locks rec but not gap —— 持有主键上的记录排他锁（不含间隙）。*** (1) WAITING FOR THIS LOCK TO BE GRANTED: … lock_mode X locks rec but not gap waiting —— 在等另一行的同类锁。事务 (2) 正好对称。最后一行 *** WE ROLL BACK TRANSACTION (2) 告诉你谁被回滚。

我读死锁日志只问三个问题：两条语句分别是什么；锁在哪个索引上（PRIMARY、二级索引还是唯一索引）；锁模式是 rec but not gap（记录锁）、gap before rec（间隙锁）还是 insert intention（插入意向锁）。三个答案凑齐，基本就能定位到代码。

这是我在业务代码里见得最多的一种：为了「防止重复下单」，先 SELECT … WHERE order_no=? FOR UPDATE，查不到就 INSERT。看起来加了锁很安全，实际上在 REPEATABLE READ 下，order_no=50001 不存在时 InnoDB 锁的是 50000 和 50002 之间的间隙。间隙锁之间互相兼容，所以两个事务都能顺利拿到；接着两边都要往这个间隙里 INSERT，需要插入意向锁，而插入意向锁和对方的间隙锁冲突——环形成。

两轮实测：会话 D 在 1.31 秒报 1213，会话 C 在 2.31 秒提交，表里最终只有一条 order_no=50001。日志里的关键行是：HOLDS … index idx_order_no … lock_mode X locks gap before rec，WAITING … lock_mode X locks gap before rec insert intention waiting。看到这两句，基本就可以确定是「先查后插」模式。

关闭死锁检测：SET GLOBAL innodb_deadlock_detect=OFF、innodb_lock_wait_timeout=5，重放场景一。没有人被立刻回滚，两个事务都等到超时，在 6.31 秒同时报 ERROR 1205，两笔转账都没成功。官方文档建议只在大量并发争抢同一热点行、死锁检测本身成为瓶颈时才关；普通业务关掉只会把 1 秒内解决的事变成 5 秒后两边都失败。

固定加锁顺序：两边先执行 SELECT id FROM accounts WHERE id IN (5,6) ORDER BY id FOR UPDATE，再按各自方向改余额。第二个事务在第一句就排队等待，第一个 1.01 秒提交后它接着执行，2.01 秒提交，两轮零死锁、两笔都生效。

唯一索引 + READ COMMITTED：把 order_no 建成 UNIQUE，会话隔离级别设为 READ COMMITTED，再重放场景二。RC 下 FOR UPDATE 不存在的值不再加间隙锁；第二个 INSERT 撞到对方还没提交的同值记录时会等待，对方 2.01 秒提交后，它得到 ERROR 1062 Duplicate entry，而不是死锁。重复下单被唯一索引挡住，应用只要把 1062 当作「已存在」处理即可。