MySQL innodb_print_all_deadlocks 怎样把死锁写入错误日志

MySQL 排查 InnoDB 死锁时，最关键的开关是 innodb_print_all_deadlocks。把它设为 ON 后，服务器会把所有 InnoDB 用户事务死锁的详细信息写入 mysqld 错误日志；不开启时，SHOW ENGINE INNODB STATUS 主要只能看到最近一次死锁。它负责留痕，不负责自动修复，也不会替应用完成事务重试。

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

最稳妥的排障闭环是：确认变量状态 → 临时开启 → 复现或等待一次死锁 → 读取错误日志和最近状态 → 记录 victim、等待资源与 SQL → 关闭变量。频繁死锁仍要回到事务访问顺序和应用重试逻辑。

先把开关作用域说清楚

这个变量的作用是让 InnoDB 把死锁详情写进 MySQL 服务器错误日志。它的作用域是 GLOBAL，支持动态修改，默认值为 OFF。因此它适合做一次临时排障开关，而不是在每个连接里单独设置的会话选项。

-- 先确认当前实例是否已经打开全部死锁留痕
SELECT @@GLOBAL.innodb_print_all_deadlocks AS print_all_deadlocks;

-- 只读取配置状态，不会触发死锁或改变事务
SHOW VARIABLES LIKE 'innodb_print_all_deadlocks';

如果查询结果是 0 或 OFF，并不代表当前没有死锁，只代表后续死锁不会全部追加到错误日志。已经发生的旧死锁也不会因为现在打开开关而补写；要观察新的记录，必须在开启后等待或复现一次新的死锁。

做一个可复现的最小排障闭环

先在具有相应管理权限的连接中打开变量。MySQL 8.4 参考手册给出的最小动作就是设置全局变量：

-- 开启后，后续每次 InnoDB 用户事务死锁都会写入错误日志
SET GLOBAL innodb_print_all_deadlocks = ON;

-- 立即复查，避免把权限错误误判成变量不生效
SELECT @@GLOBAL.innodb_print_all_deadlocks AS print_all_deadlocks;

接着用两个事务制造一个足够小的锁等待环：事务 A 先锁住行 1，再请求行 2；事务 B 先锁住行 2，再请求行 1。示例只用于测试环境或隔离的演练表，生产库不要为了验证日志而人为制造死锁。

-- 连接 A：先锁住第一行，再等待第二行
START TRANSACTION;
UPDATE deadlock_lab SET balance = balance + 1 WHERE id = 1;
-- 保持事务未提交，等待连接 B 先锁住 id=2
UPDATE deadlock_lab SET balance = balance + 1 WHERE id = 2;

-- 连接 B：反向获取锁，形成相互等待
START TRANSACTION;
UPDATE deadlock_lab SET balance = balance - 1 WHERE id = 2;
-- 这条语句会等待连接 A 持有的 id=1
UPDATE deadlock_lab SET balance = balance - 1 WHERE id = 1;

InnoDB 检测到环后会选择一个事务作为 victim 并回滚它，使另一个事务能够继续。错误日志中的死锁片段通常包含事务、锁和 SQL 等线索；应把这段记录与应用侧的事务请求时间对应起来。

错误日志和 SHOW ENGINE INNODB STATUS 怎么配合

两者不是重复入口，而是覆盖范围不同：

-- 查看最近一次死锁，适合先快速确认结构
SHOW ENGINE INNODB STATUS\G

-- 在服务器侧确认错误日志目标位置，便于交给日志采集系统
SELECT @@GLOBAL.log_error AS error_log_path;

读取错误日志时不要只截取“Deadlock found”一行。至少保留 victim 事务、等待的锁资源、涉及的表和索引、触发 SQL，以及对应时间窗口。这样才能把日志证据交给开发者调整事务访问顺序。

诊断完成后关闭开关

完成一次采集后，应立即关闭这个排障开关。关闭不会修复已经存在的事务设计问题，但能让后续运行回到默认的日志留痕范围。

-- 关闭后不再为后续每次死锁追加完整详情
SET GLOBAL innodb_print_all_deadlocks = OFF;

-- 记录关闭结果，便于把排障配置与时间窗口写入变更单
SELECT @@GLOBAL.innodb_print_all_deadlocks AS print_all_deadlocks;

如果实例重启或配置管理工具重新下发参数，也要重新确认最终状态。临时执行 SET GLOBAL 与配置文件中的启动参数不是一回事；不要把一次会话里的操作当成永久配置。

高频死锁应该追根因，不是长期打开日志

偶发死锁并不一定表示引擎异常，InnoDB 能够检测并回滚其中一个事务。真正需要处理的是频率、业务影响和是否存在可靠的重试逻辑。可以用错误日志收集一段时间的样本，然后归纳所有样本中重复出现的资源和 SQL。

• 让多个事务以相同顺序访问多张表或多组行，减少环形等待。
• 缩短事务持续时间，尽快提交一组相关修改，不要让交互式连接长时间持有未提交事务。
• 应用捕获死锁回滚后，按业务幂等性设计有限重试；记录原始请求和最终结果。
• 诊断窗口结束后关闭 innodb_print_all_deadlocks，只保留必要的日志采集周期。

相关问题

打开变量后为什么错误日志没有立刻出现内容？

开关只影响后续新发生的 InnoDB 用户事务死锁，不会回填历史事件；还要确认测试确实产生了新的死锁，并读取的是当前实例的错误日志。

只看 SHOW ENGINE INNODB STATUS 可以吗？

它适合快速查看最近一次死锁。需要统计一段时间内的多次死锁时，应在排障窗口开启全量日志，并把错误日志与应用日志关联。

innodb_print_all_deadlocks 能自动避免下一次死锁吗？

不能。它提供诊断证据；避免死锁仍要调整事务访问顺序、缩短事务并让应用正确处理回滚和重试。