最快查最近死锁用show engine innodb status并定位latest detected deadlock区块，关键看transaction id、holds/waiting for lock及末尾sql；查历史死锁须开启innodb_print_all_deadlocks=1，日志中以** (1) transaction:开头，用grep -a 50 -b 5 "record locks.space id"提取；mysql 8.0+应使用performance_schema.data_locks等新视图替代已移除的innodb_locks。
直接看最近一次死锁：用 SHOW ENGINE INNODB STATUS
这是最快、最不用配置的入口，只要死锁发生过，就一定有记录。执行后别翻全文，直接搜 LATEST DETECTED DEADLOCK 这个区块——它不是历史汇总，而是真实发生时的“现场快照”。
关键信息全在里面：TRANSACTION ID 能帮你对齐业务日志；HOLDS THE LOCK(S) 和 WAITING FOR THIS LOCK 必须对照着看，一个占着、一个等着，闭环了就是死锁证据；末尾的 SQL 语句（比如 UPDATE t1 SET ... WHERE id = ?）是你回溯代码的唯一锚点。
注意：SHOW ENGINE INNODB STATUS 只保留最后一次，反复发生会覆盖。如果应用报了十几次 Deadlock found when trying to get lock 却只看到一条记录，说明你漏掉了前面的。
查所有历史死锁：必须开 innodb_print_all_deadlocks
MySQL 默认根本不会记历史死锁，innodb_print_all_deadlocks = OFF 是出厂设置。不开这个，错误日志里就只有 MySQL 启动/崩溃等常规内容，死锁详情压根不写。
确认是否开启：SELECT @@innodb_print_all_deadlocks; 返回 1 才算生效。
临时开启（重启失效）：SET GLOBAL innodb_print_all_deadlocks = ON;
永久开启（生产环境必须）：在 my.cnf 的 [mysqld] 段落下加一行：innodb_print_all_deadlocks = 1，然后重启或热加载（RDS 可走参数模板）。
别忘了检查日志路径可写：SHOW VARIABLES LIKE 'log_error'; 查到路径后，确认 MySQL 进程用户（如 mysql）对该文件有写权限。
从错误日志里提取死锁块：别信 "LATEST DETECTED DEADLOCK"
开了 innodb_print_all_deadlocks 后，每次死锁都会往 log_error 文件里追加一段以 *** (1) TRANSACTION: 开头的完整块，不是独立文件，也不叫 “deadlock.log”。
常见错误匹配方式：
❌ grep "LATEST DETECTED DEADLOCK" /var/log/mysql/error.log —— 这个字符串只出现在 SHOW ENGINE INNODB STATUS 输出里，错误日志里根本没有；
✅ 正确模式：grep -A 50 -B 5 "RECORD LOCKS.*space id" /var/log/mysql/error.log —— 因为每段死锁日志必含 RECORD LOCKS space id；
✅ 实时监控：tail -f /var/log/mysql/error.log | grep --line-buffered -i "deadlock"（加 --line-buffered 防止缓冲延迟漏事件）。
日志会被 logrotate 切走，查历史前先确认归档文件是否存在，比如 /var/log/mysql/error.log.1.gz。
交叉验证锁状态：避开已废弃的 INNODB_LOCKS
想确认当前谁卡着谁，不能只靠死锁日志。MySQL 8.0.1+ 已彻底移除 INFORMATION_SCHEMA.INNODB_LOCKS 表，查它会直接报错。
有效组合是：
• 查活跃事务：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;
• 查锁等待关系：SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
• 查具体锁资源（MySQL 8.0+）：SELECT * FROM performance_schema.data_locks\G; —— 它能精确到索引名、页号、记录值，比旧版可靠得多。
特别注意：INNODB_LOCK_WAITS 里的 REQUESTING_TRX_ID 和 BLOCKING_TRX_ID 要和 INNODB_TRX 的 TRX_ID 对上，才能定位到真正阻塞源。
死锁日志里真正要盯的是资源定位信息，不是 SQL 文本本身。比如看到两个事务都卡在 space id 88 page no 7 index `idx_account`，基本就能断定是相同条件并发更新导致的——这时候索引设计、SQL 写法、加锁顺序，比单纯“重试”更治本。
