大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
半夜两点，手机响了。钉钉群里一片哀嚎：“订单系统挂了！大量Deadlock found！”你打开SHOW ENGINE INNODB STATUS，看到LATEST DETECTED DEADLOCK下面一大段日志——十六进制地址、锁结构体、各种缩写，每个字母都认识，串起来完全看不懂。
死锁不是bug，它是数据库并发控制机制的必然产物。区别在于：有人能在几分钟内定位根因并解决，有人说“重启试试”然后继续睡。今天我们从死锁的四种常见模式出发，建立一套从日志到根因的完整分析链。
一、死锁的四种常见模式
在深入日志之前，先建立分类框架。不同类型的死锁，日志特征和解决方案完全不同。
模式1：不同表顺序死锁
场景：事务A先更新orders再更新users，事务B先更新users再更新orders。
日志特征：两个事务各持有一张表的锁，等待另一张表。
根因：代码中未统一跨表操作的加锁顺序。
模式2：相同表不同条件死锁
场景：事务A通过二级索引锁定行1，事务B通过主键锁定行2，但索引交错形成循环。
日志特征：两个事务都涉及同一张表，但通过不同索引路径形成循环等待。
根因：复合索引设计问题，导致不同查询走了不同的索引路径。
模式3：间隙锁死锁（RR隔离级别下最常见）
场景：事务A范围查询锁住了间隙，事务B也想在同一个间隙插入数据。
日志特征：日志中出现locks gap before rec和insert intention。
根因：RR隔离级别下，间隙锁与插入意向锁冲突。
模式4：外键约束死锁
场景：高并发下更新父表时，需要检查子表，子表上有行锁。
日志特征：锁等待链涉及父表和子表。
根因：外键约束在并发场景下放大锁冲突。
二、死锁日志逐行解码
以下是一个典型的死锁日志片段：
------------------------
LATEST DETECTED DEADLOCK
------------------------
*** (1) TRANSACTION:
TRANSACTION 310298, ACTIVE 0 sec
UPDATE orders SET status = 'PAID' WHERE order_id = 10086
*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 100 page no 3 n bits 72 index PRIMARY of table `db`.`orders`
trx id 310298 lock_mode X locks rec but not gap
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 100 page no 5 n bits 72 index idx_status of table `db`.`orders`
trx id 310298 lock_mode X locks gap before rec insert intention waiting
*** (2) TRANSACTION:
TRANSACTION 310299, ACTIVE 0 sec
UPDATE orders SET status = 'SHIPPED' WHERE status = 'PAID'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS index idx_status ... lock_mode X
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS index PRIMARY ... waiting
*** WE ROLL BACK TRANSACTION (1)
关键字段解读：
| 字段 | 含义 | 分析价值 |
|---|---|---|
TRANSACTION |
事务ID | 区分两个死锁事务 |
HOLDS THE LOCK |
当前已持有的锁 | 知道对方占用了什么资源 |
WAITING FOR THIS LOCK |
正在等待的锁 | 知道自己在等什么 |
lock_mode X |
排他锁 | 写锁冲突 |
locks rec but not gap |
行锁（非间隙锁） | 普通行锁冲突 |
locks gap before rec |
间隙锁 | RR隔离级别特有，常与插入意向锁冲突 |
WE ROLL BACK |
被回滚的事务 | 谁被牺牲了 |
从日志还原死锁过程：
- 事务1持有主键
order_id=10086的行锁，在等idx_status上的锁。 - 事务2持有
idx_status上的锁，在等主键锁。 - 两个事务形成循环等待 → 死锁发生，事务1被回滚。
三、从日志特征反推死锁模式
| 日志特征 | 死锁模式 | 根因 |
|---|---|---|
| 两个事务各持不同表的锁 | 不同表顺序 | 代码未统一加锁顺序 |
| 同一张表，不同索引路径 | 相同表不同条件 | 复合索引设计问题 |
gap before rec + insert intention |
间隙锁 | RR隔离级别 |
| 涉及父表和子表 | 外键约束 | 高并发下外键开销大 |
四、真实案例：间隙锁导致的死锁
场景：库存扣减系统，先查询是否存在可用库存，再更新。并发高时频繁死锁。
日志特征：
*** (1) HOLDS: lock_mode X locks gap before rec
*** (1) WAITING: insert intention
*** (2) HOLDS: lock_mode X locks gap before rec
*** (2) WAITING: insert intention
分析：RR隔离级别下，事务A执行SELECT ... FOR UPDATE（范围查询）锁住了间隙；事务B同样锁住相同间隙；两个事务都想插入新数据，互相等待插入意向锁，形成死锁。
解决方案：将隔离级别改为READ COMMITTED（RC模式下不存在间隙锁），同时配合binlog_format=ROW保证复制安全。
五、死锁预防清单
绝大多数频繁死锁的问题，根源就两个：锁顺序混乱、事务太长。
1. 统一加锁顺序
跨表操作时，所有事务严格按相同顺序访问表和行。例如：先更新orders再更新users，所有事务都按这个顺序。
2. 拆分长事务
事务越短越好，避免在事务中调用外部API或做耗时操作。长事务意味着持有锁的时间更长，死锁概率呈指数级上升。
3. 优化索引设计
死锁往往是索引交错导致的。分析死锁日志中涉及的两个索引，考虑是否可以通过调整索引来打破循环。
4. 降低隔离级别
如果业务允许幻读，将REPEATABLE READ降为READ COMMITTED，间隙锁消失，从根本上避免间隙锁相关死锁。
5. 应用层重试机制
捕获Deadlock found异常后重试（通常1-2次即可成功），这是最直接的兜底方案。
6. 开启死锁日志SET GLOBAL innodb_print_all_deadlocks = ON，把所有死锁记录进错误日志，方便长期追踪。
死锁是一个可以系统化分析的问题。通过“分类→日志解码→反推根因→预防”四步法，你不仅能解决当前死锁，还能建立预防机制。绝大多数死锁都源于两个核心问题：锁顺序混乱、事务太长。把这两个问题解决，再配合索引优化和隔离级别调整，死锁就会从“半夜惊醒”变成“日常可控”。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
