MySQL 事务死锁日志如何映射到具体 SQL

MySQL 死锁日志里通常已经有一条“正在等待锁”的 SQL，但它不一定等于整个事务执行过的全部 SQL。比较稳妥的映射方法是：先用 SHOW ENGINE INNODB STATUS 或错误日志拿到事务、线程和锁对象，再用 Performance Schema 的 THREAD_ID、EVENT_ID 回查历史语句，最后用锁等待关系验证这条 SQL 是否真的参与了环路。

死锁日志里的事务状态、锁模式、索引页号、记录行信息可以直接和`information_schema.INNODB_LOCKS`、`INNODB_LOCK_WAITS`表的数据对应，再结合当前库下最近未提交的事务执行记录就能映射到具体的业务SQL。

先从死锁日志拿到可追踪的身份线索

InnoDB 的死锁报告重点不是“报错字符串”，而是两组事务各自持有什么锁、还想申请什么锁，以及最终被回滚的受害事务。先把下面几类字段抄出来：

这里最容易误判的是“看到一条 UPDATE，就认为事务只执行了这一条 UPDATE”。一个事务可能先锁住订单表，再锁库存表；报告只展示死锁检测时的关键语句。图 1 用静态关系示意这些身份如何连接，图中内容是解释性插图，不是实际运行截图。

打开全量记录，避免只看最后一次死锁

只想看最近一次事件时，直接执行：

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

在输出中搜索 LATEST DETECTED DEADLOCK。如果业务偶发但难以复现，建议在排查窗口打开全量记录；MySQL 会把每次 InnoDB 用户事务死锁写入 mysqld 错误日志：

-- 开启全局死锁记录，便于按时间串起多次事件
SET GLOBAL innodb_print_all_deadlocks = ON;

-- 排查结束后关闭，避免长期增加日志噪声
SET GLOBAL innodb_print_all_deadlocks = OFF;

这个开关不是“把历史补回来”的开关，开启前已经发生的死锁仍然不会出现在错误日志中。生产环境还要配合日志权限、保留周期和采集系统，记录每次报告的时间、事务 ID 与受害方。

用 Performance Schema 把锁对象与 SQL 文本对齐

如果死锁正在发生或刚发生，先从锁等待表确认关系。data_lock_waits 表示请求锁的一方被哪一个已持有的锁阻塞，下面的查询只展示身份和资源，适合先缩小范围：

-- 对齐请求方、阻塞方以及它们对应的锁资源
SELECT
  w.REQUESTING_THREAD_ID,
  w.BLOCKING_THREAD_ID,
  r.OBJECT_SCHEMA AS waiting_schema,
  r.OBJECT_NAME AS waiting_table,
  r.INDEX_NAME AS waiting_index,
  b.OBJECT_SCHEMA AS blocking_schema,
  b.OBJECT_NAME AS blocking_table,
  b.INDEX_NAME AS blocking_index
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
 AND r.ENGINE = w.ENGINE
JOIN performance_schema.data_locks AS b
  ON b.ENGINE_LOCK_ID = w.BLOCKING_ENGINE_LOCK_ID
 AND b.ENGINE = w.ENGINE;

随后用线程 ID 回查语句历史。历史表的语句是否还在，取决于消费者是否开启、历史容量以及查询距离事件发生的时间：

-- 用锁表返回的线程 ID 回查历史 SQL 文本
SELECT THREAD_ID, EVENT_ID, SQL_TEXT, CURRENT_SCHEMA, TIMER_START, TIMER_END
FROM performance_schema.events_statements_history_long
WHERE THREAD_ID IN (123, 456)
ORDER BY THREAD_ID, EVENT_ID;

-- 用连接 ID 反查账号和来源主机，辅助关联应用请求
SELECT THREAD_ID, PROCESSLIST_ID, PROCESSLIST_USER, PROCESSLIST_HOST
FROM performance_schema.threads
WHERE PROCESSLIST_ID IN (789, 790);

图 2 只画这些表和字段之间的静态关系：锁等待表提供“谁等谁”，锁表提供资源，语句历史表提供 SQL 文本。若 SQL_TEXT 为空或历史已经被覆盖，不要把当前 PROCESSLIST.INFO 当成死锁瞬间的完整证据。

验证映射并修复重复死锁

一条 SQL 能被认为是“具体死锁 SQL”，至少要满足两个条件：它属于报告中的事务或能由线程、事件历史定位到该事务；它申请或持有的表、索引、记录与报告中的锁资源一致。只对上连接 ID，不对锁对象，证据还不够。

如果历史语句采集来不及开启，仍可凭报告中的事务 ID、thread id、索引名和锁模式定位应用代码路径，但要明确标注为“报告语句”或“事务上下文”，不要声称还原了完整 SQL 序列。MySQL 官方也提醒，事务和锁表是快速变化的实时视图，跨表查询结果可能在读取过程中变得不一致。

修复时优先统一多个事务访问表和记录的顺序，缩短事务持锁时间，在应用层捕获死锁回滚后按退避策略重试；不要只把锁等待超时调大。每次改动后保留一份死锁报告和对应 SQL 映射，确认环路消失或频率下降。

相关问题

为什么 SHOW ENGINE INNODB STATUS 只能看到一条死锁？

它主要展示最近一次死锁。要收集每次事件，应在排查窗口打开 innodb_print_all_deadlocks 并从 mysqld 错误日志读取。

死锁报告里的 SQL 一定是事务第一条 SQL 吗？

不一定。它通常是检测到环路时正在等待或持锁相关的语句，完整事务历史需要提前启用语句事件采集并及时查询。

data_lock_waits 能直接返回 SQL 文本吗？

不能。它主要返回等待关系和线程、事件标识；SQL 文本要通过对应的 Performance Schema 语句事件表另行回查。