半夜被死锁日志叫醒，这绝对是DBA和后台开发最不愿面对的深夜噩梦。钉钉群里哀嚎“订单系统挂了”，打开SHOW ENGINE INNODB STATUS，看到一大串十六进制地址和锁结构体，每个字母都认识，拼在一起就是天书。
死锁本质上不是bug，而是数据库并发控制机制在特定条件下的必然产物。真正拉开差距的，是有人能在几分钟内从日志反推出根因并解决，而另一些人只能重启了事。今天就从四种常见的死锁模式说起，建立一套从日志到根因的完整分析链，下次再遇到，你也能从容应对。
一、死锁的四种常见模式
在深扒日志之前，先搭个分类框架。不同类型的死锁，日志特征和解决方案天差地别。
模式1：不同表顺序死锁
场景：事务A先更新orders再更新users，事务B正好反过来，先更新users再更新orders。
日志特征：两个事务各持一张表的锁，同时等待对方释放另一张表。
根因：代码中跨表操作的加锁顺序没有统一约定。
模式2：相同表不同条件死锁
场景：事务A通过二级索引锁定某行，事务B通过主键锁定另一行，但索引路径交错形成了循环等待。
日志特征：两个事务操作同一张表，但走的索引路径不同。
根因：复合索引设计不合理，导致不同查询走了不同的索引路径。
模式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保证复制安全即可。
五、死锁预防清单
绝大多数频繁死锁，根源只有两个：锁顺序混乱和事务太长。
- 统一加锁顺序：跨表操作时，所有事务严格按相同顺序访问表和行。比如固定先更新
orders再更新users，全员遵守。 - 拆分长事务：事务越短越好，坚决避免在事务中调用外部API或做耗时操作。持有锁的时间越长，死锁概率呈指数级上升。
- 优化索引设计：死锁往往源于索引交错。分析日志中涉及的两个索引，考虑是否可以通过调整索引来打破循环等待链条。
- 降低隔离级别：如果业务可以容忍幻读，把
REPEATABLE READ降为READ COMMITTED，间隙锁消失，间隙锁相关死锁从根本上杜绝。 - 应用层重试机制：捕获
Deadlock found异常后自动重试，通常重试1-2次就能成功，这是最直接的兜底方案。 - 开启死锁日志：执行
SET GLOBAL innodb_print_all_deadlocks = ON，把所有死锁记录进错误日志，方便长期追踪和复盘。
最后再说一句：死锁是可以系统化分析的问题。按照“分类→日志解码→反推根因→预防”四步法，你不仅能解决眼前的问题，更能建立起一套长效预防机制。把锁顺序和事务长度这两个核心问题解决了，再配合索引优化和隔离级别调整，死锁就会从“半夜惊醒的噩梦”变成“日常可控的小问题”。
