MySQL 死锁日志看不懂时先找哪两条事务

MySQL 报出死锁时，日志里的事务编号、锁模式和十六进制记录很容易把人带偏。真正应该先找的只有两端：一条事务正在等待什么，另一条事务已经持有什么锁。把这两端对上，再看 InnoDB 最后回滚了谁，基本就能还原死锁闭环。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

排查顺序可以固定为“等待者 → 阻塞者 → 回滚受害者”。不要先按事务 ID 大小猜责任，也不要把锁等待超时和已经被 InnoDB 检测到的死锁混成一件事。

死锁日志里先找持锁事务和等待事务

先拿最近一次 InnoDB 报告，不要从整段监控输出的开头读到结尾。MySQL 8.4 文档说明，SHOW ENGINE INNODB STATUS 会展示最近一次死锁；如果打开 innodb_print_all_deadlocks，则可以把每次死锁写入错误日志，便于连续事件复盘。

-- 读取最近一次 InnoDB 死锁报告
SHOW ENGINE INNODB STATUS\G

-- 需要连续保留死锁现场时再开启错误日志记录
SET GLOBAL innodb_print_all_deadlocks = ON;

在输出中直接搜索 LATEST DETECTED DEADLOCK。每个 *** (1) TRANSACTION 或 *** (2) TRANSACTION 块都要记三件事：事务编号和线程号、当前执行的 SQL、最后一次已经持有和正在等待的锁。这里的“事务一”和“事务二”只是报告中的位置，不代表谁先开始，也不代表谁一定应该回滚。

把“等待者”和“阻塞者”对成一条关系

读日志时可以把每个事务写成一行：事务 ID | SQL | 已持有对象 | 正在等待对象。例如事务 A 已持有 orders 的 X 锁，又等待 payments；事务 B 已持有 payments 的 X 锁，又等待 orders。这才是闭环，单独看到一个 LOCK WAIT 只能说明有等待，并不能证明发生了死锁。

判断时要同时比对表名、索引名、锁类型和记录值。尤其是二级索引上的记录锁，日志可能同时展示索引键和主键；只盯着一串十六进制值，容易把同一条记录看成两条。InnoDB 默认会检测死锁并回滚一个事务，所以应用仍必须把这次事务失败当成可重试信号，而不是继续等待同一把锁。

用 data_lock_waits 把两条事务连起来

死锁日志适合复盘最近一次事件；如果现场还在变化，可以用 Performance Schema 看当前锁依赖。data_lock_waits 记录请求锁的一端和阻塞锁的一端，两个事务 ID 再回到 data_locks 取得表、索引、锁模式和锁状态。

-- 关联等待端与阻塞端，先确认是哪两条事务互相卡住
SELECT
    w.REQUESTING_ENGINE_TRANSACTION_ID AS waiting_trx,
    w.BLOCKING_ENGINE_TRANSACTION_ID   AS blocking_trx,
    waiting.OBJECT_SCHEMA              AS waiting_schema,
    waiting.OBJECT_NAME                AS waiting_table,
    waiting.INDEX_NAME                 AS waiting_index,
    blocking.LOCK_MODE                 AS blocking_mode
FROM performance_schema.data_lock_waits AS w
JOIN performance_schema.data_locks AS waiting
  ON waiting.ENGINE = w.ENGINE
 AND waiting.ENGINE_LOCK_ID = w.REQUESTING_ENGINE_LOCK_ID
JOIN performance_schema.data_locks AS blocking
  ON blocking.ENGINE = w.ENGINE
 AND blocking.ENGINE_LOCK_ID = w.BLOCKING_ENGINE_LOCK_ID;

-- 再用事务 ID 回查 InnoDB 的事务状态和线程信息
SELECT trx_id, trx_mysql_thread_id, trx_started, trx_query
FROM information_schema.innodb_trx;

这里的 REQUESTING_ENGINE_TRANSACTION_ID 是等待端，BLOCKING_ENGINE_TRANSACTION_ID 是持有阻塞锁的一端。若要还原业务请求，还需要把线程号关联到连接池、应用日志或 Performance Schema 的语句事件。查询结果只代表采样时刻；死锁被回滚后，相关锁可能已经消失，不能拿一次空结果否定刚才的报错。

找到两条事务后，先修锁顺序再谈重试

如果 A 总是先更新订单再更新支付，B 却先更新支付再更新订单，最直接的修复是让两条路径遵守同一顺序。多行更新也尽量按稳定的主键顺序访问；事务只包住必要写入，提交前不要夹杂外部网络调用。对更新条件建立合适索引，可以减少无谓扫描和锁住更大范围的机会。

应用侧要区分“被选为受害者”和“根因”。受害者只是 InnoDB 为解除循环选出的一个事务，下一次可能轮到另一条。重试必须有次数上限、退避和幂等边界；如果事务包含发券、扣库存之外的外部副作用，不能简单把整段业务无条件重放。

常见问题

只看到 LOCK WAIT 就是死锁吗？

不是。锁等待可能最终正常获得锁；死锁要看等待关系是否形成闭环，或报告中是否出现死锁段和回滚决定。

死锁日志里应该先看哪个事务 ID？

先看每个事务的等待对象，再反查谁持有这个对象。事务 ID 只是关联字段，不是优先级或责任排序。

把 innodb_lock_wait_timeout 调大能解决死锁吗？

不能。死锁检测开启时，InnoDB 会主动回滚一个事务；调大等待超时可能只会让普通锁等待更久，不能消除相反顺序形成的环。