MySQL 死锁日志怎样对应到具体事务

线上看到 Deadlock found when trying to get lock 时，最容易误判的是把日志里的事务编号直接当成业务订单号。正确做法是把死锁报告拆成三类线索：事务 ID 用来确认 InnoDB 事务，MySQL thread id 用来定位连接，SQL 和锁对象用来反推具体业务动作。三者合起来，才能回答“是哪两个事务互相等待”。

官方资料：https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlocks.html

先保存完整的死锁报告，再按“事务 ID → 线程/连接 → SQL 与锁对象 → 业务入口”的顺序对应。不要只看最后一条 SQL，也不要把已经结束的连接信息当成当前现场。

本文用一个典型的订单与库存更新场景说明排查方法，重点是如何对应日志，不延伸到具体业务的重试策略。

先从死锁报告里找出两条完整线索

可以先执行下面的诊断语句，立即保存输出到工单或日志系统。SHOW ENGINE INNODB STATUS 的输出里，重点查看 LATEST DETECTED DEADLOCK 段；它通常会列出两个事务、各自持有的锁、正在等待的锁、线程号以及最近执行的 SQL。

-- 保存 InnoDB 最近一次死锁报告，\G 便于按字段阅读
SHOW ENGINE INNODB STATUS\G

-- 现场仍在持续时，列出当前连接与事务，先保留 thread_id 线索
SELECT
    p.THREAD_ID,
    p.PROCESSLIST_ID,
    p.PROCESSLIST_USER,
    p.PROCESSLIST_HOST,
    p.PROCESSLIST_DB,
    t.STATE,
    t.AUTOCOMMIT,
    t.ISOLATION_LEVEL
FROM performance_schema.threads AS p
LEFT JOIN performance_schema.events_transactions_current AS t
       ON t.THREAD_ID = p.THREAD_ID
WHERE p.TYPE = 'FOREGROUND';

报告中的 TRANSACTION 12345 是 InnoDB 内部事务标识，MySQL thread id 87 才是可以继续关联连接属性的线索。排查时应把两者分别记录，不能用一个数字替代另一个。

用线程和事务信息把日志接到具体连接

如果死锁发生后连接很快结束，现场查询可能已经看不到它，这并不表示日志不能对应。可以把死锁报告中的 thread id、用户、主机、库名和 SQL 文本，与应用连接池日志中的连接创建记录、请求 ID 或事务入口日志进行交叉匹配。现场仍存在时，下面的查询适合拿到“谁在执行”和“当前事务处于什么状态”。

-- 通过线程号关联当前语句，避免只凭事务编号猜业务
SELECT
    p.PROCESSLIST_ID AS mysql_thread_id,
    p.PROCESSLIST_USER AS db_user,
    p.PROCESSLIST_HOST AS client_host,
    p.PROCESSLIST_DB AS db_name,
    s.EVENT_ID,
    s.SQL_TEXT,
    s.ROWS_EXAMINED,
    s.ROWS_AFFECTED
FROM performance_schema.threads AS p
JOIN performance_schema.events_statements_current AS s
  ON s.THREAD_ID = p.THREAD_ID
WHERE p.PROCESSLIST_ID IN (87, 92)
ORDER BY p.PROCESSLIST_ID, s.EVENT_ID;

把示例中的 87、92 换成报告实际出现的线程号。若查询返回空结果，先判断事务是否已经回滚或连接是否已释放；不要为了“补齐”而虚构 SQL。此时应优先依靠应用侧的事务开始日志、请求 ID、数据库用户名和客户端地址。

再看锁对象，确认两方是不是同一个业务动作

对应到连接后，还要检查锁对象是否和 SQL 访问的表、索引一致。例如事务 A 先更新库存行，再更新订单行；事务 B 以相反顺序访问这两类记录。死锁报告里的“持有锁”和“等待锁”可以解释为什么这两条连接会形成环，而 SQL 文本则帮助你把它们归到库存扣减、订单状态变更或批量同步等入口。

这里有一个关键边界：死锁报告说明的是检测时的锁关系，不保证它还代表当前系统状态。InnoDB 会选择一个事务回滚来打破死锁，随后连接上的事务状态可能已经变化。因此“对应具体事务”要以报告快照和应用日志的时间窗口为准。

排查完成后留下可复查的最小记录

一次有效的死锁记录至少保留：发生时间、完整死锁段、两个事务 ID、两个 thread id、用户与主机、SQL 文本、表和索引名称，以及应用侧的请求 ID。这样下一次出现同类死锁时，可以先比较访问顺序是否一致，再判断是同一类业务入口还是新的问题。

• 日志里只有事务 ID：补采集连接池的请求 ID 和数据库连接信息。
• thread id 找不到：先确认连接已回收，再查应用事务开始/结束日志。
• SQL 看起来一样：继续比较参数、索引和锁对象，避免把两种访问范围混在一起。

总结一下：事务 ID 负责确认 InnoDB 记录，thread id 负责接到连接，锁对象负责解释等待环，SQL 和时间窗口负责落到业务入口。四层线索都对上，才算完成了从死锁日志到具体事务的对应。

相关问题

为什么只看最后一条 SQL 不够？因为事务可能已经先持有另一张表或索引上的锁，最后一条 SQL 只展示等待动作，不能还原完整访问顺序。

死锁发生后还能查询到原事务吗？不一定。被选中的事务会回滚，连接也可能随后释放；这时应使用已保存的死锁报告与应用日志交叉对应。