mysql锁表必须30秒内定位干预，否则引发雪崩；需用show processlist或information_schema.processlist筛选状态为locked、waiting for table metadata lock或time>60的线程，确认非系统线程且info为空后再kill，并联动磁盘空间监控防误操作。
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 权限，避免脚本被入侵后变成提权入口。
