如何应对MySQL锁表引发业务崩溃，构建自动监控与告警脚本？

本文共计855个文字，预计阅读时间需要4分钟。

MySQL中的表锁并非等它自己好，而是必须预先在30秒内定位并处理，否则业务请求会堆积、连接池耗尽、上游服务超时崩溃。

怎么快速识别当前是否有线程卡在 Locked 状态

直接执行 show processlist 会返回大量无关连接，真正要盯的是状态为 Locked、Waiting for table metadata lock 或运行时间远超正常值（比如 >60s）的行。

• 用 mysql -uroot -e "show processlist" | grep -E "(Locked|Waiting.*metadata|Sleep)" 快速过滤
• 注意区分：状态是 Sleep 但 Time 列数值极大（如 1200），大概率是事务没提交，也得杀
• information_schema.processlist 视图更稳定，适合脚本调用，比如：SELECT id, user, host, db, command, time, state, info FROM information_schema.processlist WHERE state REGEXP 'Locked|Waiting' OR time > 60

kill 命令不能乱发，得先确认是否安全

盲目 kill 可能导致事务回滚压力陡增、binlog位置错乱，甚至主从延迟突增。关键判断点有三个：

• 该连接是否属于应用连接池（如 HikariCP 的 HikariProxyConnection）？如果是，说明应用层已放弃等待，可杀
• 看 info 字段是否为空——空值往往代表正在等锁，而非执行中；非空则需评估 SQL 是否可中断（如大 update）
• 避免杀 system user 或 event_scheduler 类系统线程，它们不参与业务锁竞争

自动监控脚本必须带“熔断阈值”和“防抖逻辑”

一个只检测 + 发钉钉的脚本，在高峰期可能每分钟发10条告警，等于没告警。真实可用的脚本要满足：

• 连续 3 次检测到 >5 个 Locked 线程，才触发告警（防抖）
• 每次 kill 前写入日志：echo "$(date): killing $id (state: $state, time: $time)" >> /var/log/mysql-lock-killer.log
• 告警消息里必须包含 top 3 耗时最长的阻塞 SQL，方便 DBA 追查源头，例如：SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE time > 60 ORDER BY time DESC LIMIT 3
• 钉钉 Webhook 发送失败时，降级写本地文件并用 logger 推送到 syslog，避免告警静默丢失

为什么磁盘空间监控必须和锁表监控一起部署

很多“锁表”本质是磁盘写满后 MySQL 写 binlog 或 redo log 失败，进程卡在 IO 等待，状态显示为 Locked。这时候 kill 线程毫无意义，5分钟后又全卡住。

• 务必在同一个脚本里检查 df -h | awk '$5 ~ /%$/ && $5 > 90 {print $1,$5}'
• 如果发现 /var/lib/mysql 所在分区使用率 ≥90%，优先清理 slow_query_log、general_log 或过期 binlog，再处理锁
• MySQL 的 innodb_log_file_size 和磁盘空间强相关，日志文件过大 + 磁盘紧张 = 更容易假死

最常被忽略的一点：自动 kill 脚本本身不能用 root 用户长期运行，应创建专用账号并限制权限，例如只授予 PROCESS 和 RELOAD 权限，避免脚本被入侵后变成提权入口。