show engine innodb status 是唯一实时线索，其 latest detected deadlock 仅保留最近一次死锁且不落盘；需几秒内执行，否则被覆盖；error_log 默认不记录，须显式开启 innodb_print_all_deadlocks=on。
死锁发生时没有 error log，SHOW ENGINE INNODB STATUS 是唯一实时线索
MySQL 的死锁检测是异步触发的，一旦发生，InnoDB 会立即选择一个事务回滚，并把完整死锁信息写入 SHOW ENGINE INNODB STATUS 的 LATEST DETECTED DEADLOCK 区域——但这个内容只保留最近一次死锁，且不落盘到任何日志文件（除非你主动配置了定期抓取）。这意味着：如果没人恰好在死锁发生后立刻执行该命令，信息就永远丢失。
实操建议：
- 死锁发生后必须在 几秒内 执行
SHOW ENGINE INNODB STATUS\G，延迟超过 10 秒大概率已被新死锁覆盖 - 不要依赖
error_log：默认情况下，MySQL 不会 把死锁事件写入错误日志；需显式开启innodb_print_all_deadlocks = ON（5.6.2+），且该参数仅影响后续死锁，对已发生的无效 - 若应用层捕获到
Deadlock found when trying to get lock错误，应立刻在数据库侧运行上述命令，而非只记录应用日志
用 innodb_print_all_deadlocks 让每次死锁自动落盘
这是最直接、最低成本的“捕获”方式，但它不是实时推送，而是将死锁摘要追加写入 MySQL 错误日志（error_log），供事后排查。注意它只记录死锁涉及的 SQL 片段、事务 ID、等待/持有锁的资源，不包含完整堆栈或变量值。
启用步骤：
- 确认 MySQL 版本 ≥ 5.6.2（旧版本不支持）
- 在配置文件
my.cnf的[mysqld]段添加：innodb_print_all_deadlocks = ON - 重启 MySQL 或动态设置：
SET GLOBAL innodb_print_all_deadlocks = ON（注意：该变量不可动态关闭，需重启才能关） - 验证是否生效：检查错误日志中是否出现类似
*** (1) TRANSACTION:开头的块状输出
注意：该参数会轻微增加日志 I/O，但在死锁频发场景下值得开启；它不会记录事务开始时间、客户端 IP 或应用 traceID，需配合应用层日志关联。
用 Performance Schema 捕获锁等待链（MySQL 5.7+）
当死锁尚未发生、但已出现长等待时，performance_schema.data_lock_waits 表可帮你提前发现潜在冲突路径。虽然它不能“捕获死锁瞬间”，但能还原出导致死锁的锁等待关系，尤其适合复现难度高的间歇性问题。
关键操作：
- 确保 P_S 已启用：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/innoDB'（需提前开启） - 查询阻塞链：
SELECT * FROM performance_schema.data_lock_waits—— 返回BLOCKING_TRX_ID和REQUESTING_TRX_ID，再关联data_locks查具体表/行/索引 - 配合
events_statements_current获取两个事务正在执行的 SQL：SELECT THREAD_ID, SQL_TEXT FROM performance_schema.events_statements_current WHERE THREAD_ID IN (SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_ID IN (...))
限制：P_S 锁监控有性能开销，不建议长期全量开启；且 data_lock_waits 只反映“当前等待”，死锁回滚后该记录即消失，需轮询采集。
应用层重试 + 上下文透传才是防丢关键
所有服务端手段都存在窗口期或配置盲区。真正能“捕获”每一次死锁的，是在应用抛出 Deadlock found when trying to get lock 异常时，立刻记录足够上下文：SQL 原文、绑定参数、事务 ID（SELECT TRX_ID FROM information_schema.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID()）、调用栈、traceID、甚至上游请求 body。
否则，即使 DBA 看到死锁日志，也无法定位是哪个业务操作、哪类用户、哪个时间段触发的。
容易被忽略的一点：MySQL 的 innodb_print_all_deadlocks 输出里，事务 ID（如 TRANSACTION 4218594832）和 INNODB_TRX 中的 TRX_ID 并非同一数值体系——前者是内部递增计数器，后者是 64 位整数，无法直接映射。想精准关联，只能靠时间戳 + 应用层日志对齐。
