装完 MySQL 必须监控连接数，Threads_connected 表示当前 TCP 连接总数，接近 max_connections 时需预警；需结合 PROCESSLIST 定位空闲或长耗时连接，谨慎使用 KILL CONNECTION 或 KILL QUERY；应通过定时采集、Prometheus 和 Grafana 实现自动化监控与告警。
装完 MySQL 就该盯住连接数——它不爆，服务大概率不会突然挂；一爆，Too many connections 错误立刻打脸应用。关键不是“能不能连”，而是“谁连着、连多久、干没干活”。
查当前连接数用 SHOW STATUS LIKE 'Threads_connected'
这是最轻量、最常用的一招，普通账号就能跑，适合写进巡检脚本。Threads_connected 返回的是 TCP 连接总数，不管它在 Sleep 还是 Query，只要没断开就算一个。
- 值接近
max_connections（用SHOW VARIABLES LIKE 'max_connections'查）就得警觉，比如 192/200 - 别把它和
Threads_running混：后者才是真正在执行 SQL 的线程数，差值大说明一堆连接挂着不动 - 这个值是瞬时快照，没法回溯，得靠定时采集才能看出趋势
定位“谁占着不放”必须查 information_schema.PROCESSLIST
光看总数没用，得知道哪几个连接在拖后腿。用 SELECT * FROM information_schema.PROCESSLIST 能看到每个连接的 ID、USER、HOST、TIME（空闲秒数）、STATE（如 Sleep 或 Query）。
- 默认只显示当前用户自己的连接；要查全部，账号必须有
PROCESS权限 -
WHERE STATE = 'Sleep' AND TIME > 300可筛出挂了 5 分钟以上的空闲连接 -
HOST字段可能带端口（如10.0.1.5:54321），别当成不同机器误判 - 加
ORDER BY TIME DESC LIMIT 10快速揪出最老的几个“僵尸连接”
杀连接前务必分清 KILL CONNECTION 和 KILL QUERY
手抖输错 ID 会直接断业务，所以先确认状态再动手。
- 对
STATE = 'Sleep'的连接，用KILL CONNECTION 12345（把 12345 换成实际ID）——断整个连接，干净利落 - 对卡死的长查询（
STATE = 'Sending data'或'Copying to tmp table'），优先试KILL QUERY 12345——只停当前语句，连接保着，应用还能重试 -
KILL不可逆，且对事务会强制回滚，别在高峰期乱杀
监控不能只靠手动，得固化到采集链路里
人肉查一次解决不了问题，连接泄漏往往是缓慢发生的。真正管用的是把指标变成可告警的数据流。
- Shell 脚本最简单：
mysql -e "SHOW STATUS LIKE 'Threads_connected';"配合cron每分钟跑一次，输出追加到日志 - 想可视化，就往 Prometheus 推：用
mysqld_exporter自动暴露mysql_global_status_threads_connected指标，Grafana 画图+设阈值告警 - 别漏掉
Max_used_connections：它是历史峰值，比当前值更能暴露配置是否合理
连接数本身是个哑指标，真正难的是判断“该不该杀”“为什么不释放”——这得结合应用层连接池配置、SQL 执行耗时、网络超时设置一起看，单看数据库端永远只能看到一半真相。
