MySQL 死锁日志怎么反推出两条事务的加锁顺序

MySQL 死锁日志不是只看一句 “Deadlock found” 就结束。真正有用的信息集中在两条事务各自的 HOLDS THE LOCK(S) 和 WAITING FOR THIS LOCK TO BE GRANTED：前者说明已经拿到什么，后者说明还想拿什么。把这两组内容分别抄成表，再把索引名和记录值对应回 SQL，通常就能还原出“事务 A 先拿了锁 1、事务 B 先拿了锁 2，随后互相等待”的闭环。

判断加锁顺序的核心是找锁环，而不是比较日志中两条 SQL 的显示顺序。事务 A 持有 B 需要的锁，同时等待 B 持有的锁，才构成可解释的死锁证据。

先把死锁报告拆成四种证据

先执行下面的查询。它只读取最近一次 InnoDB 状态，不会主动制造锁。

-- 读取最近一次死锁、事务和锁等待摘要
SHOW ENGINE INNODB STATUS\G

-- 频繁复现时临时记录每次死锁到 mysqld 错误日志
SET GLOBAL innodb_print_all_deadlocks = ON;

在输出中定位 LATEST DETECTED DEADLOCK。对每个事务分别写下四类字段：事务标识、正在执行的 SQL、HOLDS THE LOCK(S) 下的锁、WAITING FOR THIS LOCK TO BE GRANTED 下的锁。报告末尾还会说明 InnoDB 选择回滚哪一个事务；受害者不是“最后一条 SQL”，而是引擎为打破环路选中的事务。

用 holds 和 waits 画出锁环

可以先用一张小表消除阅读方向混乱。下面的名称是假设示例，重点是记录方式，不代表某个真实业务表。

这时环路是：A 持有 PRIMARY:101，B 在等它；B 持有 idx_user_status:7，A 在等它。日志中哪条事务先打印并不能证明谁先加锁，但“持有关系 + 等待关系”已经给出了顺序约束。若只看到一个事务等待、另一个事务没有反向等待，那更像普通锁等待，应继续找完整报告或当前锁表。

MySQL 8.4 还可以观察当前瞬时关系。锁表变化很快，查询结果只能代表执行查询时的切片，不能把它当作历史死锁日志。

-- 查看当前谁请求锁、谁持有阻塞锁
SELECT
    w.REQUESTING_ENGINE_TRANSACTION_ID AS waiting_tx,
    w.BLOCKING_ENGINE_TRANSACTION_ID AS blocking_tx,
    r.OBJECT_SCHEMA, r.OBJECT_NAME, r.INDEX_NAME,
    r.LOCK_TYPE, r.LOCK_MODE, r.LOCK_DATA
FROM performance_schema.data_lock_waits AS w
JOIN performance_schema.data_locks AS r
  ON r.ENGINE_LOCK_ID = w.REQUESTING_ENGINE_LOCK_ID
WHERE r.OBJECT_SCHEMA = 'app'; -- 只缩小到业务库，按现场库名替换

把索引和记录映射回 SQL

报告里的 index PRIMARY、二级索引名以及 lock_mode X locks rec but not gap 都是定位线索，不是完整 SQL。回到事务中的 UPDATE、DELETE、SELECT ... FOR UPDATE，逐条问三个问题：

• WHERE 条件首先命中了哪个索引？
• 这个索引记录是否还需要回到聚簇主键？
• 是单记录锁，还是范围扫描带来的 next-key/gap 锁？

例如 A 先按主键更新订单，再按用户状态查找待处理记录；B 先按用户状态更新，再回头改同一个订单。即使两条 SQL 看起来都只改一行，访问了不同索引，也可能形成反向顺序。没有合适索引时，扫描范围变大，日志中出现的锁数量也可能多于业务直觉。

修复后要验证顺序，而不是只调超时

最稳妥的修复通常是让所有事务按同一顺序访问表和记录，例如都先锁定订单主键，再处理用户状态；同时让事务尽量短，并为锁定读和更新条件建立匹配索引。innodb_lock_wait_timeout 只能影响等待超时，不会把相反的加锁顺序变成安全顺序。死锁检测开启时，应用仍应捕获死锁错误并重试整笔事务，而不是只重放最后一条 SQL。

复查时保留三份证据：修复前的死锁环、修复后的执行计划或索引访问说明、连续观察窗口内的死锁日志。调试结束后关闭全量死锁日志，避免无期限增加错误日志噪声：

-- 完成取证后关闭全量死锁记录
SET GLOBAL innodb_print_all_deadlocks = OFF;

常见问题

只看 TRANSACTION 1 和 TRANSACTION 2 的顺序能判断先后吗？

不能。事务编号和文本排列是报告格式；先后应由每个事务的持有锁、等待锁以及对应 SQL 共同推断。

打开 innodb_print_all_deadlocks 后能查到历史全部日志吗？

不能追溯开启前的事件。它用于把开启后的每次死锁写入 mysqld 错误日志，日志轮转和保留策略仍由部署环境负责。