show status like 'threads_connected'直接反映当前mysql活跃连接数，即tcp连接数，不区分空闲或忙碌；threads_running才是正在执行sql的线程数。
查当前活跃连接数用 SHOW STATUS LIKE 'Threads_connected'
这个值反映 MySQL 此刻有多少客户端连着，是最直接的“连接数占用”快照。它不区分空闲还是忙碌，只看 TCP 连接是否还挂着。
常见错误是拿它当“正在执行 SQL 的数量”——其实 Threads_running 才是真正在干活的线程数。两者差值大，说明很多连接挂在那里没关，可能在等应用层释放。
- 执行
SHOW STATUS LIKE 'Threads_connected'后，结果里的Value列就是数字 - 配合
SHOW VARIABLES LIKE 'max_connections'看上限，算出占用率（比如 192/200 就得警觉） - 该命令无需特殊权限，普通账号也能跑，适合加到监控脚本里定时采集
看谁连着、连了多久用 SELECT * FROM information_schema.PROCESSLIST
这是定位“哪个应用占着不放”的唯一办法。PROCESSLIST 里每行代表一个连接，关键字段有：ID（线程 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），别误判为不同机器
连接数暴增时怎么快速断开异常连接
发现某个 ID 占着不放，又确认不是业务必需，就该 Kill 掉。别手抖输错 ID——KILL 不可逆，且对正在执行的事务会强制回滚。
真实场景中，常有人用 KILL CONNECTION 和 KILL QUERY 混淆：KILL CONNECTION 断整个连接（推荐用于 Sleep 状态），KILL QUERY 只停当前语句（适合卡死的长查询，但连接还在）。
- 先查：
SELECT ID, USER, HOST, TIME, STATE FROM information_schema.PROCESSLIST WHERE TIME > 300 - 再杀：
KILL CONNECTION 12345（把 12345 换成实际 ID） - 杀完立刻再查一次
Threads_connected，看是否回落——如果没变，说明新连接又上来了，得查应用层连接池配置
为什么监控脚本里不能只看 Threads_connected？
因为这个值本身不带时间维度，也不告诉你连接从哪来、干了什么。线上出问题时，你看到 198/200，但不知道是 10 个 Java 应用各占 20 个，还是某个 Python 脚本泄漏了 150 个。
更麻烦的是，MySQL 重启后计数清零，而连接池（如 HikariCP、Druid）可能在重连时并发建连，瞬间打满上限，触发拒绝连接（错误信息：Too many connections）。
- 真正有用的监控组合是：
Threads_connected+Threads_created（每秒创建新连接数）+Aborted_connects（失败连接数） -
Threads_created持续升高，基本等于应用没复用连接，得查连接池maxActive或maximumPoolSize配太小或没生效 - 别依赖单次查询，至少每 10 秒采一次，画趋势图才能看出是突发 spike 还是缓慢爬升
连接数问题从来不在 MySQL 自身，而在应用怎么建、用、关。查 PROCESSLIST 时多看两眼 HOST 和 TIME，比调 max_connections 管用十倍。
