必须修改配置文件并重启MySQL才能使innodb_print_all_deadlocks真正生效；动态SET GLOBAL仅对新连接临时有效且重启丢失，还需确保log_error路径可写、log_error_services含log_sink_internal、log_error_verbosity≥3。
innodb_print_all_deadlocks 必须写进配置文件并重启才生效
动态执行 SET GLOBAL innodb_print_all_deadlocks = ON 看似成功，但只对后续新建连接临时有效，已存在的连接（包括绝大多数生产连接）完全不受影响；MySQL 重启后该设置丢失。它本质是只读变量，所谓“动态设置”只是欺骗性兼容。真正起效的唯一路径是修改配置文件：
- 编辑
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf - 在
[mysqld]段下添加：innodb_print_all_deadlocks = ON - 执行
systemctl restart mysql（或对应服务名） - 重启后验证：
SELECT @@innodb_print_all_deadlocks;返回ON才算落地
死锁日志实际输出到哪？先确认 log_error 路径
开启后死锁日志不会单独成文件，而是追加到 MySQL 的错误日志（log_error 指定路径）中。很多人配完搜不到记录，根本原因是压根没去对地方找：
- 必须运行
SHOW VARIABLES LIKE 'log_error';查真实路径，常见如/var/log/mysql/error.log、/var/lib/mysql/hostname.err - 若返回空或
NULL，说明错误日志被禁用（例如 systemd 配置了StandardError=journal），死锁信息会直接丢弃 - 检查路径可写：
ls -ld $(dirname $(mysql -Nse "SELECT @@log_error"))，确保属主是mysql用户且有写权限
log_error_services 缺失 log_sink_internal 就白配
MySQL 8.0 错误日志由组件系统驱动，innodb_print_all_deadlocks 开关只是“触发器”，真正落盘依赖 log_error_services 链路完整：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 执行
SELECT @@GLOBAL.log_error_services;，正确值应为log_filter_internal; log_sink_internal - 若含
log_sink_null、为空、或只有log_sink_json但log_error指向文件，则死锁日志不会出现在 .err 文件中 - 修复方式（持久化）：
SET PERSIST log_error_services = 'log_filter_internal; log_sink_internal'; - 若 MySQL 已无法启动，必须手动在配置文件
[mysqld]下添加log_error_services = log_filter_internal; log_sink_internal
log_error_verbosity ≥ 3 否则死锁事件被静默过滤
即使前面全对，若日志级别太低，死锁块仍不会写入。MySQL 默认 log_error_verbosity = 2（只记 warning 及以上），而死锁记录属于 Note 级别：
- 必须设为
3：log_error_verbosity = 3写入配置文件并重启 - 验证方式：用错误密码连一次，再
tail -n 10 /var/log/mysql/error.log | grep "Access denied"，有输出才算生效 - 监听死锁时注意管道缓冲：
tail -f /var/log/mysql/error.log | grep --line-buffered -i "TRANSACTION\|deadlock"，否则可能漏掉实时块
真正难的不是改几个参数，而是意识到这四个条件缺一不可：配置文件里的 innodb_print_all_deadlocks = ON、正确的 log_error 路径与权限、完整的 log_error_services 组件链、以及足够高的 log_error_verbosity 级别。少一个，日志就静默消失。
