必须开启innodb_print_all_deadlocks=ON，否则仅靠SHOW ENGINE INNODB STATUS只能捕获最后一次死锁，无法反映生产环境高频批量死锁的真实分布；需在my.cnf中配置并重启，日志输出至log_error指定文件，结合HOLDS/WAITING锁信息与SQL语句定位事务冲突根源。
必须立刻开 innodb_print_all_deadlocks = ON，否则你看到的永远只是冰山一角。
为什么 SHOW ENGINE INNODB STATUS 只能帮你解决 10% 的问题
它只保留最近一次死锁，而生产环境里高频死锁往往批量发生——你查到的可能是凌晨三点那个孤立 case，不是白天每分钟都在撞的主路径。更麻烦的是，SHOW ENGINE INNODB STATUS 不记录时间戳、不带上下文堆栈、不关联应用线程 ID，纯靠人工对 SQL 猜业务逻辑。
- 临时生效：
SET GLOBAL innodb_print_all_deadlocks = ON; - 持久化配置：在
my.cnf的[mysqld]段加innodb_print_all_deadlocks = 1，并确认log_error路径 MySQL 进程有写权限（否则静默失效） - 日志量可控：单次死锁日志约 2–5 KB，远小于慢查询日志；但若每秒超 10 次，说明代码层已失控，别先想着关它
从死锁日志里快速定位冲突点的三步法
拿到 error log 里的 *** (1) TRANSACTION 和 *** (2) TRANSACTION 块后，不要读全文，盯这三项：
- 看
trx query—— 找出最后卡住的那句 SQL，它未必是第一句，但一定是触发等待的临界点 - 比对
HOLDS THE LOCK(S)和WAITING FOR THIS LOCK TO BE GRANTED—— 如果都落在同一个索引（比如idx_user_id），且 lock_mode 是X locks rec but not gap，基本就是同一行被两个事务先后UPDATE - 查
lock_mode类型 —— 出现gap或next-key，说明涉及范围查询或非唯一索引，得立刻检查 WHERE 条件是否走了索引、有没有隐式类型转换
真正降低死锁率的三个硬动作
日志只能告诉你“谁锁了谁”，不能自动修复。根因 80% 以上来自应用层行为失控：
- 强制统一 DML 顺序：比如所有涉及
orders和inventory的事务，无论哪个接口入口，都必须先UPDATE orders再UPDATE inventory（反过来也行，但必须全局一致） - 消灭隐式锁扩大：检查所有报死锁的 SQL 是否走了预期索引，
EXPLAIN看type是否为const/ref；WHERE 条件字段没索引？立刻加 - 拆长事务：事务里调用外部 HTTP、做复杂计算、sleep 或等 MQ 回执？这些必须挪到事务外——锁持有时间越长，撞上其他事务的概率呈指数上升
死锁不是数据库故障，是并发逻辑暴露出来的信号。最危险的不是第一次死锁，而是你 fix 掉一条 SQL 后，同类模式在另一条路径里继续静默发生——所以一定要从日志里反推调用链，而不是只修表层 SQL。
