死锁发生在多个事务互相等待对方持有的资源时。InnoDB 会检测死锁并回滚其中一个事务。工程上要做的不是幻想完全避免死锁，而是降低概率并正确重试。

1. 学习定位

维度	内容
难度层级	故障排查
核心目标	先会用，再理解机制，最后能做工程取舍和故障分析
学习方法	带着业务场景看命令、SQL、数据结构、日志和运行时指标

2. 核心地图

死锁分析与处理
├─ 资源顺序
├─ 等待图
├─ Deadlock Detected
├─ Victim Rollback
├─ 重试
├─ 幂等
└─ 锁范围

3. 小章节深度讲解

下面把核心地图中的每个点拆开讲。每个小节都同时面向开发和运维：开发侧关注怎么设计、怎么写代码、怎么避免错误；运维侧关注怎么监控、怎么定位、怎么恢复。

3.1. 资源顺序

是什么

资源顺序 属于 MySQL 并发控制。锁不是简单阻塞工具，而是数据库在多事务并发下保护一致性、范围约束和表结构安全的机制。

开发人员怎么用

开发人员要让更新条件命中索引，统一资源访问顺序，并把重试设计成幂等。涉及状态、库存、余额的写入，要用条件更新缩小锁范围。

运维人员怎么看

运维人员要从阻塞链分析：持锁事务、等待事务、锁类型、索引路径、事务年龄和 SQL 来源。必要时结合 Performance Schema 与 InnoDB status。

常见风险

常见风险是无索引更新或长事务遇到 DDL，行锁、间隙锁和 MDL 叠在一起，最后表现为整张表像被冻住。

3.2. 等待图

是什么

等待图 属于 MySQL 并发控制。锁不是简单阻塞工具，而是数据库在多事务并发下保护一致性、范围约束和表结构安全的机制。

开发人员怎么用

开发人员要让更新条件命中索引，统一资源访问顺序，并把重试设计成幂等。涉及状态、库存、余额的写入，要用条件更新缩小锁范围。

运维人员怎么看

运维人员要从阻塞链分析：持锁事务、等待事务、锁类型、索引路径、事务年龄和 SQL 来源。必要时结合 Performance Schema 与 InnoDB status。

常见风险

常见风险是无索引更新或长事务遇到 DDL，行锁、间隙锁和 MDL 叠在一起，最后表现为整张表像被冻住。

3.3. Deadlock Detected

是什么

Deadlock Detected 是 SQL 语言和优化器执行模型的一部分。SQL 是声明式语言，写法会影响优化器能否下推过滤、利用索引、减少排序和临时表。

开发人员怎么用

开发人员要写可优化的 SQL：字段类型匹配，避免在索引列上包函数，JOIN 条件完整，分页和排序有索引支撑。复杂 SQL 要先拆解数据流。

运维人员怎么看

运维人员要通过慢日志、执行计划、临时表指标、排序指标和 CPU/IO 观察 SQL 成本。报表查询应与在线交易隔离。

常见风险

常见风险是把所有计算塞进一条 SQL，测试数据没问题，生产数据一大就拖垮主库。

3.4. Victim Rollback

是什么

Victim Rollback 属于 MySQL 并发控制。锁不是简单阻塞工具，而是数据库在多事务并发下保护一致性、范围约束和表结构安全的机制。

开发人员怎么用

开发人员要让更新条件命中索引，统一资源访问顺序，并把重试设计成幂等。涉及状态、库存、余额的写入，要用条件更新缩小锁范围。

运维人员怎么看

运维人员要从阻塞链分析：持锁事务、等待事务、锁类型、索引路径、事务年龄和 SQL 来源。必要时结合 Performance Schema 与 InnoDB status。

常见风险

常见风险是无索引更新或长事务遇到 DDL，行锁、间隙锁和 MDL 叠在一起，最后表现为整张表像被冻住。

3.5. 重试

是什么

重试 属于 MySQL 并发控制。锁不是简单阻塞工具，而是数据库在多事务并发下保护一致性、范围约束和表结构安全的机制。

开发人员怎么用

开发人员要让更新条件命中索引，统一资源访问顺序，并把重试设计成幂等。涉及状态、库存、余额的写入，要用条件更新缩小锁范围。

运维人员怎么看

运维人员要从阻塞链分析：持锁事务、等待事务、锁类型、索引路径、事务年龄和 SQL 来源。必要时结合 Performance Schema 与 InnoDB status。

常见风险

常见风险是无索引更新或长事务遇到 DDL，行锁、间隙锁和 MDL 叠在一起，最后表现为整张表像被冻住。

3.6. 幂等

是什么

幂等 属于 MySQL 并发控制。锁不是简单阻塞工具，而是数据库在多事务并发下保护一致性、范围约束和表结构安全的机制。

开发人员怎么用

开发人员要让更新条件命中索引，统一资源访问顺序，并把重试设计成幂等。涉及状态、库存、余额的写入，要用条件更新缩小锁范围。

运维人员怎么看

运维人员要从阻塞链分析：持锁事务、等待事务、锁类型、索引路径、事务年龄和 SQL 来源。必要时结合 Performance Schema 与 InnoDB status。

常见风险

常见风险是无索引更新或长事务遇到 DDL，行锁、间隙锁和 MDL 叠在一起，最后表现为整张表像被冻住。

3.7. 锁范围

是什么

锁范围 属于 MySQL 并发控制。锁不是简单阻塞工具，而是数据库在多事务并发下保护一致性、范围约束和表结构安全的机制。

开发人员怎么用

开发人员要让更新条件命中索引，统一资源访问顺序，并把重试设计成幂等。涉及状态、库存、余额的写入，要用条件更新缩小锁范围。

运维人员怎么看

运维人员要从阻塞链分析：持锁事务、等待事务、锁类型、索引路径、事务年龄和 SQL 来源。必要时结合 Performance Schema 与 InnoDB status。

常见风险

常见风险是无索引更新或长事务遇到 DDL，行锁、间隙锁和 MDL 叠在一起，最后表现为整张表像被冻住。

3.8. 本篇学习实验

建议准备一个至少百万行级别的测试表，分别观察正常查询、缺失索引、错误索引、长事务、锁等待和慢查询日志。每次实验都记录 SQL、执行计划、耗时、扫描行数和 MySQL 状态变量变化。

开发侧实验重点是理解 SQL 与事务边界，运维侧实验重点是理解指标如何变化。真正掌握本篇内容，应该能从现象反推 SQL、索引、锁、日志或存储引擎问题。

4. 核心机制

• 死锁检测会构建等待关系，发现环路后选择一个代价较小的事务回滚。
• 不同 SQL 命中不同索引，可能以不同顺序加锁，从而产生死锁。
• 批量更新、范围更新、唯一键冲突和外键检查都是常见死锁来源。
• 被回滚事务会收到死锁错误，应用必须能识别并进行有限重试。

5. 工程实践

• 统一业务资源访问顺序，例如总是先更新账户小 ID 再更新大 ID。
• 缩短事务时间，减少一次事务触碰的行数。
• 捕获死锁错误并做有限次幂等重试。
• 保留 SHOW ENGINE INNODB STATUS 的死锁片段和对应 SQL。

6. 常见坑

• 应用遇到死锁直接返回失败，没有重试和幂等。
• 只看被回滚 SQL，不看另一个事务持有什么锁。
• 批量任务与在线流量同时更新同一批热点数据。
• 通过无限重试掩盖设计问题，造成雪崩。

7. 专家视角

• 死锁分析核心是等待图，不是单条 SQL。
• 专家会通过缩小锁范围、统一顺序和拆分事务降低死锁概率。
• 死锁是高并发系统的正常故障类型，必须被纳入应用错误模型。

8. Tips 快问快答

Q：死锁能完全避免吗？

A：很难。目标是降低概率并正确处理。

Q：死锁后数据会坏吗？

A：不会。InnoDB 会回滚其中一个事务，应用需要重试或补偿。

Q：分析死锁看什么？

A：看两个事务各自 SQL、已持有锁、等待锁、索引路径和访问顺序。

9. 阶段小结

死锁分析与处理 的学习重点不是记住零散概念，而是把它放回真实系统：数据如何进入、如何存储、如何被查询、如何在并发下保持正确、如何在故障后恢复。掌握这些连接关系，才能从“会用”走向“能设计、能优化、能排障”。