MySQL死锁监控：从日志解析到告警闭环
处理数据库死锁，有点像给系统做体检——关键不在于永远不生病，而在于生病时能第一时间发现、诊断，并知道如何应对。今天，我们就来拆解一下MySQL死锁监控的常见手段与实用补全方案。
怎么看当前有没有死锁发生
最直接的办法，就是执行 SHOW ENGINE INNODB STATUS。不过，这里有个常见的理解误区：输出里出现 “LATEST DETECTED DEADLOCK” 并不意味着死锁正在发生，它只表明最近1小时内，系统检测到并已自动回滚了一个死锁事务。这个段落仅保留最后一次死锁的完整信息，历史记录会被覆盖。
所以，反复执行却看不到这个段落，可能有两种情况：要么是死锁刚被处理完、新的还没来；要么是事务设计本身（比如周期极短、隔离级别低或未竞争同一行数据）就没触发死锁检测机制。
- 权限要注意：执行这个命令的账号必须具备
PROCESS权限。普通只读账号会静默失败——不报错，但输出内容里根本不包含InnoDB状态信息。 - 输出是纯文本：结果是一大段非结构化的文本，需要手动定位“LATEST DETECTED DEADLOCK”开始的地方。
- 重启即清空：如果MySQL实例重启过，这块记录就被清空了，无法追溯更早的历史。
死锁日志里哪些字段真正有用
面对一大段死锁日志，该盯哪里？核心看三块：TRANSACTION 行（看事务ID和状态）、mysql tables in use（看涉及了哪些表），以及每个事务下面的 WAITING FOR THIS LOCK TO BE GRANTED 和 HOLDS THE LOCK(S)。
这能帮你快速判断问题的性质：是两个事务在争同一行的排他锁（X锁），还是跨表、跨索引，甚至是间隙锁（gap lock）引发的连锁等待。
- 锁等待关系：先找到
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:，看它在等哪个索引、哪条记录（比如主键索引上的id=123）。然后往下找*** (2) HOLDS THE LOCK(S):，对比持有的锁是否正好是对方等待的资源。 - 间隙锁信号：如果看到
lock_mode X locks gap before rec insert intention waiting这类描述，基本可以确定是插入操作时的间隙锁冲突。这和唯一键无关，更多与索引的范围扫描有关。 - 事务活跃时间：事务开头的
ACTIVE 34 sec表示它已经卡了34秒。这其实是个危险信号，说明应用层可能没有设置事务超时，或者没有正确捕获死锁异常，导致事务长时间挂起。
为什么 SHOW ENGINE INNODB STATUS 不够用
这个命令提供的只是一个静态快照，而非连续监控。它没有精确的时间戳（通常只到秒），也无法进行聚合统计。线上环境一旦出现高频死锁，靠人工反复执行这个命令来抓取，响应速度根本跟不上。
此外，性能和兼容性上也有考量：频繁执行命令本身开销不大，但输出内容可能高达几MB（尤其在大事务多的场景），网络传输和人工解析的成本不低。MySQL 8.0+ 虽然提供了 performance_schema.data_locks 这样的系统表，但默认并未开启，且需要额外配置权限。
- 难以区分根因：日志看不出加锁的顺序逻辑。比如，批量导入数据时，如果固定好各表的加锁顺序就能避免死锁，但日志里无法体现这个设计缺陷。
- 信息缺失：查不到应用端的线程ID、SQL原始语句（只有语句摘要的hash值）以及客户端IP，这使得反向定位到具体的代码位置非常困难。
- 有功能但默认关闭：从MySQL 5.7开始，可以通过设置
innodb_print_all_deadlocks = ON将每次死锁记录到错误日志中。但这个参数默认是关闭的，而且错误日志往往没有进行集中收集。
怎么低成本补上监控缺口
一个务实且低成本的监控方案，是结合参数配置与日志采集。具体来说：开启 innodb_print_all_deadlocks，然后用日志采集工具（如Filebeat）收集错误日志，并配置一个简单的告警规则——例如，每分钟错误日志中间出现 “Deadlock found when trying to get lock” 超过2次，就触发通知。
参数设置上需要注意：在my.cnf中配置该参数后需要重启MySQL（5.7+版本支持动态修改，但建议重启以确保生效）。开启后，每次死锁都会以更精简的格式追加到错误日志中，虽然比 SHOW ENGINE INNODB STATUS 少了些事务堆栈细节，但足以用于发现和计数。
- 别依赖慢查询日志：试图用慢查询日志来抓死锁SQL往往行不通，因为引发死锁的语句执行速度可能很快，只是锁等待导致了循环依赖，它本身并不“慢”。
- 应用层要捕获错误码：应用代码必须显式捕获并处理MySQL错误号1213（对应错误信息
Deadlock found when trying to get lock），而不能仅仅把它当作普通信息记录。 - 测试与生产的区别：在测试阶段，可以查询
performance_schema.data_lock_waits来观察实时的锁等待链。但在生产环境需谨慎使用，因为查询这类系统表本身可能加剧锁竞争。
说到底，对待死锁的目标未必是“彻底消灭”，而是要做到“心中有数”：知道它在哪里发生、为什么发生、发生之后系统能否妥善处理。把日志收集打通、让告警生效、确保应用有合理的重试机制，剩下的，就是评估业务是否能承受重试带来的短暂延迟——这一点，恰恰最容易被人忽略。
