必须立即执行SHOW ENGINE INNODB STATUS\G并搜索LATEST DETECTED DEADLOCK，它仅保留最近一次死锁的内存快照，新死锁发生即覆盖；生产环境须配置innodb_print_all_deadlocks=1落盘全量日志并配合information_schema实时抓取锁等待链。
死锁日志不是“查不到”，而是默认只留最后一次、且不落盘——不主动配置，线上出问题时基本等于没日志。
SHOW ENGINE INNODB STATUS 只能看最近一次死锁
执行 SHOW ENGINE INNODB STATUS\G 后，在输出里搜 LATEST DETECTED DEADLOCK，就能看到最近一次死锁的完整现场：两个事务各自的 SQL、持有的锁、等待的锁、事务 ID 和线程 ID。但注意：
- 这个信息是内存中的，新死锁一发生，旧的就立刻被覆盖
- 如果死锁发生在凌晨，你白天登录再查，大概率只剩空壳
- 它不记录时间戳精度（只有“几秒前”），难以和业务日志对齐
必须开启 innodb_print_all_deadlocks=ON 才能持久化
靠 SHOW ENGINE INNODB STATUS 做事后分析远远不够。生产环境务必在 MySQL 配置中启用全量死锁日志：
- 临时生效（重启失效）：
SET GLOBAL innodb_print_all_deadlocks = ON; - 永久生效：在
my.cnf的[mysqld]段下加两行：innodb_print_all_deadlocks = 1 log_error = /var/log/mysql/error.log
- 确认是否生效：
SHOW VARIABLES LIKE 'innodb_print_all_deadlocks';返回ON即可
开启后，每次死锁都会原样写入错误日志，带毫秒级时间戳，可直接用 grep -i deadlock /var/log/mysql/error.log 定位。
别只盯着死锁日志，要结合 information_schema 实时抓现场
死锁报错（ERROR 1213 (40001): Deadlock found when trying to get lock）发生时，事务已被回滚，但锁等待链可能还残留。这时要立刻查：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 当前活跃事务：
SELECT * FROM information_schema.INNODB_TRX\G，重点关注trx_state、trx_started、trx_query - 谁在等谁：
SELECT * FROM information_schema.INNODB_LOCK_WAITS\G，能直接看到 blocking_trx_id 和 requesting_trx_id - 锁的具体对象（MySQL 8.0+）：
SELECT * FROM performance_schema.data_locks;，可定位到表名、索引名、锁模式（如RECORD或INSERT_INTENTION）
这三张表组合起来，比单看死锁日志更能还原“为什么是这两条 SQL 碰上了”。
容易忽略的关键点：日志路径权限与轮转策略
即使开了 innodb_print_all_deadlocks，也常因以下原因看不到日志：
-
log_error指定的路径 MySQL 进程无写权限（常见于自定义路径未chown mysql:mysql） - 日志被 logrotate 清理过，但没配置
copytruncate，导致 MySQL 还往旧 fd 写，实际内容丢失 - 错误日志里混着大量无关信息，建议用
tail -f /var/log/mysql/error.log | grep -i --line-buffered "deadlock"实时监听
真正卡住排查节奏的，往往不是看不懂日志，而是压根没拿到完整日志——配完记得 ls -l 看权限，grep 看是否真有输出。
