从「知道死锁」到「真正理解死锁」：一次 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是理解锁行为的“显微镜”