MySQL连接数监控：从基础指标到实战排错
在数据库运维中，连接数问题堪称“经典高频故障”。很多人一遇到“Too many connections”就手忙脚乱，其实解决问题的钥匙，就藏在几个简单的系统状态变量和系统表里。今天，我们就来彻底讲清楚，如何精准地监控、分析和处置MySQL的连接数占用。
查当前活跃连接数用 SHOW STATUS LIKE 'Threads_connected'
想快速知道数据库“挤不挤”？第一个要看的指标就是它。Threads_connected这个值，直接反映了此刻有多少个客户端正连着MySQL服务器，相当于一张实时快照。不过这里有个关键点：它只统计TCP连接是否存在，可不管连接是忙是闲。
新手常犯的一个错误，就是把它当成“正在干活”的线程数。其实，真正在执行SQL的线程数，要看另一个指标——Threads_running。如果这两个值差距很大，那就意味着有不少连接只是挂着，处于空闲状态，很可能在等待应用层释放。
- 操作很简单：执行
SHOW STATUS LIKE 'Threads_connected'，结果中的Value列就是当前连接数。 - 光看绝对数不够，得结合
SHOW VARIABLES LIKE 'max_connections'看看上限是多少。算一下占用率（比如192/200），一旦超过80%，就该拉响警报了。 - 这个命令对权限要求很低，普通账号也能执行，非常适合嵌入到监控脚本里做定时采集。
看谁连着、连了多久用 SELECT * FROM information_schema.PROCESSLIST
知道了“有多少”，下一步就得搞清楚“都是谁”。这时候，information_schema.PROCESSLIST表就成了唯一的神器。这张表里的每一行，都代表一个活跃的连接，关键字段一目了然：ID（线程唯一标识）、USER（登录用户）、HOST（客户端来源IP和端口）、TIME（当前状态已持续秒数，对于空闲连接就是空闲时间）、STATE（状态，比如Sleep表示空闲，Query表示正在执行查询）。
使用时有两点特别容易踩坑：默认情况下，你只能看到自己账号建立的连接；想查看所有连接，你必须拥有PROCESS全局权限，这通常只授予DBA或专用的监控账号。
- 用
WHERE COMMAND = 'Sleep' AND TIME > 60这样的条件，能轻松筛出空闲超过1分钟的“疑似泄漏连接”。 - 结合
ORDER BY TIME DESC LIMIT 10，能快速定位到最老的那几个“僵尸连接”，优先处理。 - 注意
HOST字段的格式（例如10.0.1.5:54321），它包含了客户端端口，别把同一个IP的不同端口误判成多台机器。
连接数暴增时怎么快速断开异常连接
定位到问题连接后，如果确认其非业务必需，就该果断清理。使用KILL命令务必谨慎——这个操作不可逆，并且会强制回滚该连接上正在执行的事务。
在实际操作中，KILL CONNECTION和KILL QUERY经常被混淆。简单来说：KILL CONNECTION [ID]是终止整个连接（推荐用于处理长期Sleep的空闲连接）；而KILL QUERY [ID]只停止当前正在执行的语句，连接本身依然保持。后者更适合处理那些卡死的长查询，暂时“止血”。
- 标准操作流程是：先查询
SELECT ID, USER, HOST, TIME, STATE FROM information_schema.PROCESSLIST WHERE TIME > 300，找出空闲超5分钟的连接。 - 确认后执行
KILL CONNECTION 12345（将12345替换为实际的线程ID）。 - 执行完毕后，立即再次检查
Threads_connected。如果数值没有回落，说明有新的连接又快速建立起来了，问题的根源很可能在应用层的连接池配置上，需要进一步排查。
为什么监控脚本里不能只看 Threads_connected？
因为这个指标虽然直观，但信息维度太单一。它只告诉你一个瞬时总数，既没有时间趋势，也不揭示连接的来源和行为。线上告警时，你看到连接数198/200，但无法判断这是10个Ja va应用各自持有了20个健康连接，还是某个脚本发生了连接泄漏，独占了150个。
更棘手的情况是数据库重启后：Threads_connected计数会清零，而应用端的连接池（比如HikariCP、Druid）在尝试重连时，可能会并发创建大量新连接，瞬间冲垮max_connections上限，导致新的应用请求全部收到“Too many connections”错误。
- 一个健壮的监控方案需要组合指标：
Threads_connected（当前数） +Threads_created（每秒新建连接数） +Aborted_connects（失败的连接尝试数）。 - 如果
Threads_created持续走高，几乎可以断定应用没有有效复用连接，得去检查连接池的maxActive或maximumPoolSize参数是否配置过小，或者配置根本没生效。 - 切记，不要依赖单次快照。至少以10秒为间隔持续采集数据，画出趋势图，才能分辨出问题是突发峰值还是缓慢增长，这是定位根因的关键。
说到底，连接数问题，十之八九根源不在MySQL数据库本身，而在于应用程序是如何创建、使用和关闭连接的。下次排查时，多花两分钟仔细看看PROCESSLIST里的HOST和TIME字段，往往比盲目调大max_connections参数要管用十倍。
