要读懂SHOW ENGINE INNODB STATUS中的死锁片段，需定位LATEST DETECTED DEADLOCK小节，重点分析编号(1)(2)两事务的TRANSACTION id、HOLDS THE LOCK(S)和WAITING FOR THIS LOCK，结合space id/page no/index反查表与索引，识别加锁顺序冲突；注意其仅为最后一次死锁快照，无时间戳/IP等信息，高频场景应启用innodb_print_all_deadlocks=ON记录全量死锁日志。
怎么看懂 SHOW ENGINE INNODB STATUS 里的死锁片段
MySQL 每次检测到死锁后，会在 SHOW ENGINE INNODB STATUS 输出中保留**最近一次**的完整死锁信息，位置固定在 LATEST DETECTED DEADLOCK 小节。它不是实时日志流，而是快照——所以如果连续发生多次死锁，你只能看到最后一次的细节。
关键点在于：这个输出不包含时间戳、事务发起客户端 IP 或应用层 traceID，纯靠锁资源和 SQL 推断逻辑路径。容易踩的坑是直接跳去看“被回滚的是哪个事务”，却忽略两个事务各自的加锁顺序和索引使用情况。
- 用
Ctrl+F快速定位到LATEST DETECTED DEADLOCK字样开始读 - 重点关注带
*** (1)和*** (2)编号的两段事务描述，它们构成死锁环 - 每段里找三类信息：
TRANSACTION id（事务 ID）、HOLDS THE LOCK(S)（持有什么锁）、WAITING FOR THIS LOCK（等什么锁） - 末尾的
WE ROLL BACK TRANSACTION (1)是 MySQL 的决策结果，不是原因——真正原因藏在前两段的锁依赖关系里
如何从锁信息反推出冲突的 SQL 和索引
死锁日志里不会直接写 “UPDATE users SET …”，但会暴露锁落在哪张表、哪个索引、哪一页上。核心线索是 space id、page no 和 index 字段。
比如出现：RECORD LOCKS space id 88 page no 7 index `idx_account`，说明锁发生在 idx_account 这个二级索引的第 7 页；而 RECORD LOCKS space id 88 page no 3 index `PRIMARY` 则指向聚簇索引（主键）的第 3 页。这两者往往属于同一张表，只是访问路径不同。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 用
SELECT NAME, SPACE FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE SPACE = 88;查出表名 - 再查该表的索引：
SELECT INDEX_NAME, INDEX_TYPE FROM INFORMATION_SCHEMA.INNODB_SYS_INDEXES WHERE SPACE = 88; - 结合业务逻辑，反推哪些 SQL 会同时命中
idx_account和PRIMARY—— 很可能是“先按 account 字段查，再更新主键行”的组合操作 - 注意：如果日志里出现
supremum pseudo-record，说明发生了间隙锁（gap lock）冲突，大概率是范围查询（如WHERE age BETWEEN 20 AND 30）惹的祸
为什么 SHOW ENGINE INNODB STATUS 不够用？必须配合 innodb_print_all_deadlocks
SHOW ENGINE INNODB STATUS 只存最后一次死锁，线上高并发场景下，很可能你刚连上去，死锁就又发生了好几次，而你只看到一个过时的样本。这是它最大的实操缺陷。
真正能用于归因分析的，是开启全局死锁日志记录：innodb_print_all_deadlocks=ON。它会把每次死锁都追加进 MySQL 错误日志（log_error 指定路径），带时间戳、完整上下文，适合做聚合分析或对接监控系统。
- 配置需写入
my.cnf并重启：[mysqld] innodb_print_all_deadlocks=ON log_error=/var/log/mysql/error.log
- 错误日志里每段死锁以
*** (1) TRANSACTION:开头，格式和SHOW ENGINE完全一致，但不会被覆盖 - 别指望靠
SHOW ENGINE抓到“偶发但高频”的死锁——那是日志文件的活儿 - 注意磁盘空间：死锁本身不频繁，但如果配置不当（比如日志轮转没开），长期运行可能撑爆
/var/log
怎么确认是不是真死锁，而不是锁等待超时？
MySQL 报错 ERROR 1213 (40001): Deadlock found when trying to get lock 才是真死锁；而 ERROR 1205 (40001): Lock wait timeout exceeded 是锁等待超时，本质是单向阻塞，不是循环等待。两者在 SHOW ENGINE INNODB STATUS 中表现完全不同：
- 死锁一定有
LATEST DETECTED DEADLOCK小节，且明确写出两个事务互相 HOLD/WAIT - 锁等待超时不会触发死锁检测机制，
LATEST DETECTED DEADLOCK小节要么不存在，要么内容陈旧 - 查当前阻塞关系，应看
INFORMATION_SCHEMA.INNODB_LOCK_WAITS表：SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;—— 这里能直接看到谁在等谁、等了多久 - 事务长时间卡住但没报错？优先查
INNODB_TRX表里的trx_started和trx_state，判断是否事务没提交、锁没释放
最常被忽略的一点：死锁日志里的 SQL 是“导致死锁的最后一句”，但它未必是问题根源——真正的隐患往往是前面几条语句已经持有了部分锁，只是最后一步才闭合了环。得顺着事务 ID 去翻应用日志，把整条执行链补全。
