MySQL 死锁：根源剖析与线上治理实战

四月 22, 2023

技术

在分布式高并发的后端架构中，数据库死锁（Deadlock）就像一个幽灵。尽管 InnoDB 引擎具备全自动的自救回滚机制，但频繁出现的死锁报错（错误码 1213）不仅会吞噬系统吞吐量，更是代码健壮性不足的显性信号。本文去掉生活化的类比，直接从资源竞争的结构本质出发，层层递进地拆解 MySQL 死锁的底层逻辑。

一、什么是死锁？从"单行道上的对向车"说起

在数据库定义中，死锁是指两个或多个事务在执行过程中，因争夺同一个锁资源而造成的一种相互等待、双向锁死的现象。若无外力介入，它们都将无限期地挂起。

类比： 想象一条窄窄的单行道，只能容一辆车通过。两辆车从对向同时驶入：

事务 A（车）：驶入路段（持有了资源 A），但前方被事务 B 的车堵住（等待资源 B）
事务 B（车）：驶入路段（持有了资源 B），但前方被事务 A 的车堵住（等待资源 A）

两辆车谁也退不回去（事务无法回滚自己的已持有锁），谁也过不去——没有外部交警（数据库死锁检测器）强行拖走一辆，这段路永远堵死。

数据库中的本质： 这就是死锁的四个必要条件——专业上称为 Coffman 条件：

互斥：锁资源一次只能被一个事务持有
持有并等待：事务在持有锁的同时，请求新的锁
不可抢占：锁只能由事务主动释放，不能被强制抢走
循环等待：事务之间形成闭合的等待环路

MySQL InnoDB 的死锁检测器正是通过检测"环路"来发现死锁，并强制回滚其中一个事务来打破僵局。

二、经典的死锁场景（多步事务交错更新）

绝大多数线上死锁都符合"多步 SQL 交错更新"的模式。当多个并发事务以不同的顺序锁定了相同的行记录，死锁就会发生。

账户互转：经典的交叉加锁

事务 1 尝试将账户 1 的钱转给账户 2；并发的事务 2 尝试将账户 2 的钱转给账户 1：

时间线	事务 1（账户 1 ➡️ 账户 2）	事务 2（账户 2 ➡️ 账户 1）	锁状态分析
T1	`UPDATE account SET balance = balance - 100 WHERE id = 1;`	—	事务 1 成功获取 id=1 的行级排他锁（X锁）
T2	—	`UPDATE account SET balance = balance - 100 WHERE id = 2;`	事务 2 成功获取 id=2 的行级排他锁（X锁）
T3	`UPDATE account SET balance = balance + 100 WHERE id = 2;`	—	事务 1 尝试申请 id=2 的 X锁，被事务 2 阻塞，进入等待
T4	—	`UPDATE account SET balance = balance + 100 WHERE id = 1;`	事务 2 尝试申请 id=1 的 X锁，被事务 1 阻塞。死锁环路达成！

核心教训： 两个事务以相反的顺序访问同一批资源（1→2 vs 2→1），是死锁的典型诱因。

三、硬核进阶：单条 SQL 引发的隐式死锁

许多开发者存在一个认识误区：“我把业务精简到了极点，每个事务只有一根单条 SQL，这样绝对不会触发死锁吧？”

答案是否定的。 即便代码层面每个事务只有一条 SQL，在 MySQL 引擎执行层面，依然可能由于底层索引扫描机制，分裂为隐含的多阶段加锁，从而诱发死锁。

情景 A：批量更新语句的扫描顺序交错

当一条语句需要更新多行记录时（例如 WHERE id IN (...) 或范围条件），MySQL 在底层是逐行扫描并加锁的。如果两个并发事务锁定的行集合存在交集，且由于索引选择、执行计划或物理存储顺序的差异，导致底层加锁次序发生交错，就会形成单句死锁。

场景复现：

表 t 有两条记录 id=1 和 id=2。两个客户端同时下发批量更新：

事务 1：UPDATE t SET balance = 100 WHERE id IN (1, 2);
事务 2：UPDATE t SET balance = 200 WHERE id IN (2, 1);

虽然代码层只是单句 SQL，但 InnoDB 内部实际加锁时序如下：

时间	事务 1	事务 2	引擎层面实际发生了什么
T1	扫描到 id=1，成功获取 X锁	—	事务 1 锁定 id=1
T2	—	扫描到 id=2，成功获取 X锁	事务 2 锁定 id=2
T3	继续对 id=2 加锁	—	事务 1 尝试锁定 id=2，被事务 2 阻塞，等待
T4	—	继续对 id=1 加锁	事务 2 尝试锁定 id=1，被事务 1 阻塞。死锁形成！

底层本质： 单条批量语句在引擎内部被"多步化执行"，扫描路径的微小差异导致了加锁次序的交错。

情景 B：间隙锁的持有与插入意向锁冲突

在 REPEATABLE READ（可重复读）隔离级别下，InnoDB 为了杜绝幻读，引入了间隙锁（Gap Lock）。间隙锁之间是完全兼容的，多个事务可以同时持有同一段间隙的共享间隙锁。然而，当这些事务随后尝试在相同间隙内执行插入时，间隙锁需要升级为插入意向锁（排他性），此时就会发生互相咬死的死锁。

场景复现：

表 t 主键为 id，当前数据库中不存在 id=5 的记录。两个事务同时执行：

时间	事务 1	事务 2	锁的转化细节
T1	`SELECT * FROM t WHERE id = 5 FOR UPDATE;`	—	id=5 不存在，事务 1 获得区间间隙锁（Gap Lock，S模式）
T2	—	`SELECT * FROM t WHERE id = 5 FOR UPDATE;`	间隙锁互相兼容，事务 2 也获得同一区间的间隙锁
T3	`INSERT INTO t (id, name) VALUES (5, 'A');`	—	事务 1 尝试插入，触发插入意向锁，被事务 2 的间隙锁阻塞，等待
T4	—	`INSERT INTO t (id, name) VALUES (5, 'B');`	事务 2 同样尝试插入，被事务 1 的间隙锁阻塞。死锁检测器立即触发！

底层本质： 两个事务在第一阶段都成功获取了共享的防守性间隙锁（持有资源），在第二阶段同时将锁状态向排他性的插入意向锁升级（索要资源），瞬间演变为双向死结。

四、线上死锁现场排查指南

面对线上死锁，切忌盲目猜测代码。应当直接调取 MySQL 的官方死锁报告：

SHOW ENGINE INNODB STATUS;

在返回结果中找到 LATEST DETECTED DEADLOCK 板块，下面是一个典型的输出示例：

------------------------
LATEST DETECTED DEADLOCK
------------------------
2026-06-16 15:30:22 0x70000c1bc000
*** (1) TRANSACTION:
TRANSACTION 28434, ACTIVE 5 sec starting index read
mysql id 12, query id 456 localhost root updating
UPDATE account SET balance = balance - 100 WHERE id = 1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 42 page no 3 n bits 72 index PRIMARY of table `demo`.`account`
trx id 28434 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 8; hex 8000000000000001; asc ;;  # 正在等待 id=1 的主键行锁

*** (2) TRANSACTION:
TRANSACTION 28435, ACTIVE 3 sec starting index read
mysql id 13, query id 457 localhost root updating
UPDATE account SET balance = balance + 100 WHERE id = 2
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 42 page no 3 n bits 72 index PRIMARY of table `demo`.`account`
trx id 28435 lock_mode X locks rec but not gap
 0: len 8; hex 8000000000000001; asc ;;  # 事务 2 正持有 id=1 的行锁
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 42 page no 3 n bits 72 index PRIMARY of table `demo`.`account`
trx id 28435 lock_mode X locks rec but not gap waiting
 0: len 8; hex 8000000000000002; asc ;;  # 事务 2 在等待 id=2 的行锁
*** WE ROLL BACK TRANSACTION (2)

核心关注点：

WAITING FOR：事务正在等待的锁
HOLDS THE LOCK(S)：事务当前持有的锁
WE ROLL BACK：InnoDB 决策回滚哪个事务（通常是代价较小的那个）

生产防护： 为防止高并发下死锁日志被冲刷，推荐开启：

SET GLOBAL innodb_print_all_deadlocks = ON;

这样所有死锁都会实时写入 error.log，便于事后回溯。

五、斩断死锁的黄金设计法则

治理死锁的核心指导思想是：破坏死锁的"循环等待"条件，尽可能压缩锁的粒度与持有持续时间。

1. 推行固定的资源访问顺序

针对情景 A 与经典死锁：如果需要同时操作多条记录，必须事先对其进行排序。

List<Long> ids = Arrays.asList(2L, 1L);
Collections.sort(ids);  // 确保永远按 id=1 → id=2 正序加锁

无论哪个线程执行，永远按照同一顺序加锁，将"交错锁死"转变为线性的"排队竞争"。

2. 精简事务，剥离非核心逻辑

严禁在数据库事务（如 Spring 的 @Transactional）内部编排 RPC 远程调用、大规模缓存刷新、文件读写等高耗时操作。事务应**“快进快出”**，持锁时间越短，并发冲突概率越低。

3. 构建严谨的索引（防止锁升级）

如果 UPDATE 或 DELETE 语句的 WHERE 条件没有命中索引，MySQL 将被迫实施全表扫描，导致行级锁疯狂升级为近乎表级锁的效果。务必通过 EXPLAIN 确保每条改动语句达到 range 或 const 级别。

4. 微调隔离级别（针对情景 B）

如果业务场景对"可重复读"没有绝对的硬性要求，强烈建议将隔离级别降为 READ COMMITTED（读已提交）。在此隔离级别下，间隙锁（Gap Lock）将不复存在，直接根除情景 B 中的诡异死锁。

5. 分批局部处理（大事务拆解）

针对大批量删除或更新，加挂 LIMIT 条件分片执行：

DELETE FROM t WHERE status = 1 LIMIT 500;

每次小步快跑，减小锁波及的范围，同时利于控制主从复制延迟。

6. 应用层构筑健壮的重试机制

在高并发的分布式环境中，死锁往往具有偶发性。在应用层代码中，应当捕获死锁异常（SQLState = 40001 或 ErrorCode = 1213），并配置指数退避（Exponential Backoff）+ 随机 jitter 的重试机制。通常 3 次内部重试即可化解绝大多数偶发死锁，大幅度提升系统的整体高可用性。

结论： 死锁不是玄学，它的本质是资源访问顺序不一致 + 持锁时间过长。理解 InnoDB 的加锁机制（行锁、间隙锁、插入意向锁），遵循固定顺序访问资源、缩短事务持锁时间、合理设计索引与隔离级别，加上应用层的重试兜底，就能将死锁从"频繁报错的幽灵"变成"可预测可控制的常态化事件"。