MySQL死锁日志默认记录在错误日志中，需开启innodb_print_all_deadlocks=ON并查询@@log_error获取路径；日志含两个事务块，关键看HOLDS与WAITING FOR的索引及主键值以定位冲突；原始SQL需结合performance_schema或应用日志反查；SHOW ENGINE INNODB STATUS仅保留最后一次死锁且易丢失，不可替代错误日志。
怎么看 MySQL 的死锁日志在哪里
MySQL 的死锁信息默认只记录在错误日志（error log）里，不是 general_log 或 slow_query_log。而且必须开启 innodb_print_all_deadlocks，否则只在发生死锁时写一条简略提示（比如 “Deadlock found when trying to get lock”），根本看不到事务详情。
- 默认情况下，
innodb_print_all_deadlocks是 OFF，要手动打开：SET GLOBAL innodb_print_all_deadlocks = ON;
- 错误日志路径由
log_error变量决定，查它：SELECT @@log_error;
，常见位置是/var/log/mysql/error.log或/usr/local/mysql/data/hostname.err - 注意：该设置不持久，MySQL 重启后失效；要永久生效，需写入配置文件
my.cnf的[mysqld]段：innodb_print_all_deadlocks = ON
死锁日志里哪些字段最关键
一段典型的死锁日志包含两个事务（TRANSACTION）块，每块里有 mysql tables in use、locked tables、LOCK WAIT、WEIGHT、undo log entries 等。真正能定位冲突 SQL 的只有两处：
- 每个事务末尾的
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:后面的RECORD LOCKS行，会显示被等待的索引名和具体主键值，例如：RECORD LOCKS space id 123 page no 456 n bits 72 index <code>PRIMARY</code> of table <code>db</code>.<code>t_user</code> trx id 1002345 lock_mode X locks rec but not gap waiting
- 紧接着的
*** (1) HOLDS THE LOCK(S):块，说明当前事务持有哪些锁（注意：它可能持的是另一行的锁，和上面等待的不是同一行）
关键不是看“谁等谁”，而是比对：
- 两个事务各自
HOLDS的索引 + 主键值 - 和各自
WAITING FOR的索引 + 主键值
→ 冲突点就出现在“A 持有 a 行锁却等 b 行锁，B 持有 b 行锁却等 a 行锁”
怎么反查出原始 SQL（尤其是预编译场景）
死锁日志里不会直接打印 SQL 文本，只记录线程 ID（MySQL thread id 123）和事务开始时间（trx started at ...）。要还原 SQL，得靠关联信息：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先从日志里提取线程 ID（如
123）和时间戳（如2024-05-20 14:22:33） - 查
performance_schema.events_statements_history_long（需提前开启相关 consumers）：SELECT SQL_TEXT FROM performance_schema.events_statements_history_long WHERE THREAD_ID = 123 AND EVENT_TIME > '2024-05-20 14:22:30' ORDER BY EVENT_TIME LIMIT 5;
- 如果没开 performance_schema 或历史被覆盖，只能靠应用层日志：检查对应时间点应用输出的 SQL（尤其注意 ORM 自动生成的 UPDATE/DELETE，比如 Hibernate 的
UPDATE t_user SET status=? WHERE id=?）
注意：如果 SQL 是通过 PREPARE/EXECUTE 执行的，日志里显示的是 Execute stmt，真实语句得去查 prepared_statements_instances 表或应用代码里的 PREPARE 字符串。
为什么用 SHOW ENGINE INNODB STATUS 看不到最近死锁
SHOW ENGINE INNODB STATUS 输出里确实有 LATEST DETECTED DEADLOCK，但它只保留最后一次死锁信息，且每次新死锁发生就会覆盖前一次。一旦你没及时执行这条命令，就丢失了。
- 它不替代错误日志，只是临时快照
- 日志中可能有连续多次死锁，但
INNODB STATUS只反映最后一次 - 更麻烦的是：某些 MySQL 版本（如 5.7.20+）在高并发下，这个字段可能为空，即使错误日志里已写入多条
所以线上排查必须依赖开启 innodb_print_all_deadlocks 后的错误日志，而不是依赖 SHOW ENGINE INNODB STATUS。
死锁日志本身不长，但交叉比对两个事务的持有锁与等待锁，需要耐心。最容易忽略的是：事务可能在 BEGIN 后执行了多条语句，而死锁只发生在最后那条，但持锁行为来自前面某条 —— 所以不能只盯着报错那条 SQL，得把整个事务的语句链路串起来看。
