必须配置innodb_print_all_deadlocks=ON并重启MySQL，日志追加至log_error指定的错误日志文件；该参数不可动态持久生效，需写入my.cnf的[mysqld]段并验证SELECT @@innodb_print_all_deadlocks返回1。
怎么让MySQL把每次死锁都记下来
只靠 SHOW ENGINE INNODB STATUS\G 会丢日志，因为它只存最后一次。要持续捕获，必须开 innodb_print_all_deadlocks = ON。
这不是临时开关，得写进配置文件并重启 MySQL：
- 编辑
my.cnf（或my.ini），在[mysqld]段落里加一行：innodb_print_all_deadlocks = ON - 确认错误日志路径（执行
SHOW VARIABLES LIKE 'log_error';查看），死锁日志就追加到那个文件里 - 重启 MySQL 生效；验证是否成功：执行
SELECT @@innodb_print_all_deadlocks;，返回1才算开对
别用 SET GLOBAL innodb_print_all_deadlocks = ON 临时开启——它在某些版本重启后失效，线上环境必须落盘配置。
死锁日志里哪些字段真正有用
日志里 SQL 文本只是线索，真正定位冲突本质的是资源定位信息：
-
space id和page no：说明两个事务卡在同一个数据页上，大概率是并发更新同一组主键或索引值 -
index `xxx`：明确锁在哪张表哪个索引上，比如index `idx_user_id`vsindex `PRIMARY`，就能看出是不是访问顺序不一致 -
lock_mode X或lock_mode S：X 是排他锁（UPDATE/DELETE），S 是共享锁（SELECT ... LOCK IN SHARE MODE），混合出现容易引发等待链 -
locks rec but not gap表示纯记录锁；gap before rec则涉及间隙锁——后者在 RR 隔离级别下极易因范围查询交叉触发死锁
看到 *** (1) WAITING FOR THIS LOCK 和 *** (2) HOLDS THE LOCK(S) 出现在不同索引、不同 page no，基本就是“事务 A 先查 idx，再改主键；事务 B 反过来”，这是最典型的环路成因。
为什么不能用 general_log 替代死锁日志
general_log 记所有 SQL，但完全不包含锁信息，也没事务上下文关联。它带来的问题更严重：
- 性能损耗极大，尤其高并发时，I/O 和磁盘写入压力直线上升
- 日志体积爆炸，一条死锁可能对应几十上百条普通语句，根本没法快速定位哪两条 SQL 在争抢
- 没有
HOLDS / WAITING结构，无法还原资源持有关系，等于丢了最关键的一环
死锁日志是 InnoDB 内核级输出，精准聚焦锁等待闭环；general_log 是客户端命令流水账，二者解决的问题完全不同。
排查时容易忽略的兼容性细节
MySQL 8.0+ 已移除 INFORMATION_SCHEMA.INNODB_LOCKS 和 INNODB_LOCK_WAITS，但很多人还在查旧文档：
- 想看当前锁状态，改用
performance_schema.data_locks和performance_schema.data_lock_waits -
innodb_status_output_locks = ON要慎开——它会让SHOW ENGINE INNODB STATUS输出巨量锁细节，拖慢诊断速度，且对死锁回溯无直接帮助 - 如果业务用了 ORM（如 MyBatis、GORM），注意其自动生成的 WHERE 条件顺序可能不一致，导致相同逻辑在不同请求中加锁顺序不同——这才是很多“偶发死锁”背后的真实原因
死锁日志本身不会告诉你业务逻辑错在哪，但它会暴露两件事：谁在等、谁在占，以及它们等和占的到底是同一片数据，还是两片互不相干却形成环路的数据——这个判断，必须结合索引结构和业务代码一起做。
