最准方式是执行 SHOW PROCESSLIST（需SUPER/PROCESS权限查全部），或查 information_schema.PROCESSLIST 表统计非Sleep连接数；Threads_connected 含僵尸连接，Threads_running 才近似真实活跃数。
怎么查 MySQL 当前活跃连接数
直接看 SHOW PROCESSLIST 是最常用也最准的方式，它列出所有当前连接的线程状态。但注意：默认只显示当前用户能看到的会话，要查全部得有 SUPER 或 PROCESS 权限。
-
SHOW FULL PROCESSLIST能看到完整 SQL（避免被截断），适合排查长查询 - 普通用户执行
SHOW PROCESSLIST可能只看到自己发起的连接，看不到其他用户会话 - 如果连接数暴涨但没明显业务增长，先别急着扩容，大概率是应用没正确释放连接
用 information_schema.PROCESSLIST 表做统计更灵活
相比命令行输出，查表能配合聚合、过滤和定时监控，比如快速算出活跃连接数：
SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep';
这个 COUNT(*) 就是真正干活的连接数（排除了空闲的 Sleep 状态）。
-
COMMAND = 'Sleep'表示连接空闲，正等着新请求；Command = 'Query'才是正在执行 SQL -
TIME字段单位是秒，值很大（比如 > 600）的Sleep连接，可能是应用忘记 close() 或连接池配置不合理 - 该表不支持索引，大并发下频繁查可能轻微拖慢 performance_schema，但日常诊断完全没问题
为什么 show status like 'Threads%' 的结果经常不准
SHOW STATUS LIKE 'Threads%' 返回的是几个计数器，其中 Threads_connected 是当前总连接数，但它包含已断开但还没被回收的“僵尸连接”，而 Threads_running 才接近真实活跃数。
-
Threads_connected偏高？检查应用是否用了短连接又没及时mysql_close() -
Threads_running长期 > 50，且Queries增速慢，说明很多连接卡在锁或 IO 上，不是 CPU 问题 - 这两个值是瞬时快照，不能替代
PROCESSLIST看具体线程在干啥
用 pt-kill 自动杀掉异常连接（谨慎操作）
当发现大量 Query 状态且 TIME > 300 的连接，手动 kill 太累，可以用 Percona Toolkit 的 pt-kill：
pt-kill --busy-time 300 --kill --victim all --interval 10
它每 10 秒扫一次，杀掉运行超 5 分钟的查询。
- 务必先加
--print参数预览要杀哪些线程，别一上来就--kill - 生产环境慎用
--victime all，优先选oldest或按--match-command Query过滤 - 如果应用本身依赖长事务（如报表导出），误杀会导致业务失败，得提前跟开发对齐容忍阈值
真正难的不是看到连接多，而是区分哪些该留、哪些该砍——空闲连接积压往往暴露的是连接池 maxIdle/maxWait 配置失当，而不是数据库扛不住。
