从「知道死锁」到「真正理解死锁」：一次 MySQL 锁机制的学习记录

1. 为什么我觉得"我懂死锁"，但又好像没真懂？

在学习 MySQL 的过程中，死锁几乎是一个"必学概念"：

两个事务
互相等待
数据库回滚其中一个

这些我很早就知道了。

但在真正开始深入 MySQL 锁机制之前，我发现一个问题：

我能复述死锁的定义，却无法解释"为什么这条 SQL 一定会死锁，那条却不会"。

也就是说------
我知道结论，但不知道推理过程。

这篇文章，就是我补齐这段认知缺口的记录。

2. 从一个最小可理解的死锁场景开始

我没有从复杂 SQL 或高并发场景入手，而是选择了最简单、最纯粹的例子：

复制代码

-- 事务 A
SELECT * FROM orders WHERE id = 1 FOR UPDATE;
SELECT * FROM orders WHERE id = 2 FOR UPDATE;

-- 事务 B
SELECT * FROM orders WHERE id = 2 FOR UPDATE;
SELECT * FROM orders WHERE id = 1 FOR UPDATE;

这段代码里，没有：

join
范围查询
二级索引
间隙锁

只有 主键 + 行锁 + FOR UPDATE。

但它依然会产生死锁。

这一步让我意识到：

死锁的关键，并不在 SQL 有多复杂，而在锁是"如何一步步加上的"。

3. 用 InnoDB 状态输出，第一次"看到"死锁

通过执行：

复制代码

SHOW ENGINE INNODB STATUS\G

我第一次不是"听说"，而是亲眼看到了死锁的细节。

在 LATEST DETECTED DEADLOCK 中，我关注的是三点：

每个事务已经持有什么锁
每个事务正在等待什么锁
InnoDB 最终回滚了哪一个事务

当我把这三点对照着 SQL 顺序去看时，死锁突然变得非常直观：

事务 A：

持有 id = 1 → 等待 id = 2
事务 B：

持有 id = 2 → 等待 id = 1

这不再是一个抽象概念，而是一个可以画出来的等待关系。

4. 我真正理解的关键点：死锁不是"锁的问题"，而是"顺序的问题"

在这之前，我一直下意识地把问题归结为：

"用了 FOR UPDATE，所以死锁了。"

但这次学习让我意识到，这是一个错误归因。

真正决定是否会死锁的，是：

多个事务对多行数据的加锁顺序是否一致

如果顺序一致：

后来的事务只会等待
不会形成环

如果顺序不一致：

在并发条件下
环形等待几乎是必然的

这一步，是我从"现象记忆"走向"机制理解"的转折点。

5. 为什么数据库不能自动帮我们避免这种死锁？

一个我一开始很自然的疑问是：

既然数据库知道我要锁 id=1 和 id=2，

那为什么不一次性全锁住，避免死锁？

后来我才明白：

InnoDB 是逐行加锁
SQL 的执行路径是边扫描、边加锁
数据库无法提前知道你后面还会锁哪些行

所以：

死锁并不是数据库的"缺陷"，而是并发执行下的必然风险。

6. 这次学习对我最大的改变是什么？

在这次系统性理解死锁之后，我最大的收获不是"会解决死锁"，而是：

我终于知道在看一段 SQL 时，应该关注什么。

我会开始主动问自己：

这个事务会锁几行？
加锁顺序是否确定？
并发事务的顺序是否一致？
是否存在形成环的可能？

这些问题，才是真正有价值的"死锁意识"。

7. 小结：这是一次认知升级，而不是知识新增

回头看这次学习，我并没有学到多少"新名词"，但我补齐了三块关键认知：

死锁是锁等待关系的结果
锁等待关系由加锁顺序决定
SHOW ENGINE INNODB STATUS 是理解锁行为的"显微镜"