死锁不是某条 SQL 天生有问题，而是多个事务的持锁与等待形成了环。
本文使用MySQL 5.6、InnoDB 与独立测试数据库。数据库研究要同时观察表结构、数据分布和实际语句。本文讨论 InnoDB（事务存储引擎），不把其他存储引擎或后续版本特性当作相同行为。
1. 从现象推到机制
两个事务以相反顺序更新两行，都拿到第一行锁后再等对方的第二行，就构成环。统一锁顺序可以减少这一类问题，但索引范围锁和复杂访问路径还需要结合实际日志分析。
图中的四个节点分别表示事务甲、事务乙、等待关系、恢复策略。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
在测试库两个连接中构造反向更新，记录 InnoDB 最新死锁信息。业务层把死锁重试限定在整个事务并设置次数，而不是只重发最后一句。
1
2
3
-- A: update row 1, then row 2
-- B: update row 2, then row 1
SHOW ENGINE INNODB STATUS;
先保存建表语句、索引与隔离级别，再准备固定演示数据。并发行为使用两个独立连接按顺序执行；执行计划、锁等待和最终数据需要结合，单看查询耗时不足以解释原因。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 两边反向取得行锁 | 可能形成相互等待环 |
| 统一按编号升序更新 | 可减少该类顺序冲突 |
| 只重试失败的最后语句 | 可能丢失事务整体语义 |
对照 1：两边反向取得行锁
可能形成相互等待环。观察时记录各自持有与请求的锁。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：统一按编号升序更新
可减少该类顺序冲突。观察时记录实际访问行与索引顺序。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：只重试失败的最后语句
可能丢失事务整体语义。观察时记录事务是否已被回滚。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
死锁可由数据库检测并选择受害事务，但应用必须处理失败。盲目无限重试会放大压力，也可能重复执行事务外副作用。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“只重试失败的最后语句”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
