innodb_print_all_deadlocks在MySQL 5.7中不存在，仅8.0.21+引入；5.7只能通过定期执行SHOW ENGINE INNODB STATUS提取LATEST DEADLOCK块或使用pt-deadlock-logger等外部工具捕获死锁详情。
innodb_print_all_deadlocks 这个参数在 MySQL 5.7 中并不存在 —— 它是 MySQL 8.0.21 才引入的。你在 5.7 环境下配置它，MySQL 启动会直接报错或忽略，日志里也不会有任何效果。
为什么 innodb_print_all_deadlocks 在 MySQL 5.7 不生效
MySQL 5.7 的 InnoDB 死锁日志机制只支持「最近一次死锁」记录，固定输出到 SHOW ENGINE INNODB STATUS 的 LATEST DEADLOCK 段落中。官方未提供将每次死锁都写入错误日志的开关。你看到的文档或博客若声称 5.7 支持该参数，基本是混淆了版本，或误把 8.0 的配置套用到了 5.7。
验证方式很简单：
- 执行
SELECT @@innodb_print_all_deadlocks;→ 报错Unknown system variable - 在
my.cnf中添加innodb_print_all_deadlocks = ON并重启 → MySQL 启动失败（error log 中提示 unrecognized variable）
MySQL 5.7 中真正可用的死锁日志方案
想让每次死锁都留下可追溯痕迹，只能靠组合手段：启用错误日志 + 定期抓取 INNODB STATUS + 主动解析。
-
log-error = /var/log/mysql/error.log必须开启（默认通常已开），这是所有死锁事件的「唯一落点」——因为每次死锁发生时，MySQL 都会在 error log 里写一条类似这样的记录：2026-05-06T10:23:45.123456Z 12345 [ERROR] [MY-013113] [InnoDB] Deadlock found when trying to get lock; try restarting transaction - 搭配
innodb_lock_wait_timeout = 50（建议设为 30~60 秒），避免长时间卡住掩盖死锁频次 - 定期轮询（如每 5 秒）执行
SHOW ENGINE INNODB STATUS\G并提取LATEST DEADLOCK块，写入独立文件或转发到日志系统（注意并发执行可能被阻塞，需加锁或限流）
容易被忽略的关键细节
很多团队以为只要开了 log-error 就万事大吉，但实际排查时发现 error log 里只有那句「Deadlock found...」，没有上下文。这是因为：
- MySQL 5.7 默认不把完整的死锁事务堆栈写进 error log，只留提示；完整信息只存在于内存中的
INNODB STATUS输出里，且每次新死锁会覆盖前一次 -
SHOW ENGINE INNODB STATUS是单线程串行操作，高并发下频繁调用会导致自身阻塞，反而干扰业务 - 如果你依赖监控脚本自动采集，必须确保脚本能处理连接超时、权限不足（需要 PROCESS 权限）、以及输出截断（status 输出可能超长）
真要长期稳定捕获，得用外部工具（比如 pt-deadlock-logger）配合定时任务，而不是指望一个不存在的参数一劳永逸。
