Threads_connected 是 MySQL 内部准确统计的当前已建立连接总数（含 Sleep、Query 等所有状态），而 SHOW PROCESSLIST 默认仅显示非 Sleep 线程且受权限限制，无法完整反映真实连接数。
直接看 Threads_connected 就够了，SHOW PROCESSLIST 是用来查“谁在连、在干啥”，不是数连接数的工具。
为什么 SHOW PROCESSLIST 不适合统计当前连接数
它只显示非 Sleep 状态的线程（默认过滤掉空闲连接），且结果行数受权限限制：普通用户看不到其他用户的连接。即使你看到 87 行，真实连接数可能是 120+。
-
SHOW PROCESSLIST默认等价于SHOW FULL PROCESSLIST的精简版，但不包含完整 SQL 和 Host 信息 - 如果执行用户没有
PROCESS权限，只会返回自己的连接，严重低估总数 - 它不包含处于
Sleep状态但尚未关闭的连接——而这部分常占总连接数 60% 以上
真正该用的命令是 SHOW STATUS LIKE 'Threads_connected'
这个值才是 MySQL 内部维护的、准确的当前已建立连接总数（含 Sleep + Query + Connect 等所有状态）。
- 返回字段
Value就是数字，无需解析文本或计数行数 - 不需要特殊权限，任意能连上数据库的账号都能执行
- 和
mysqladmin status输出里的Threads:值完全一致，可交叉验证 - 注意：它不含已断开但尚未被回收的僵尸连接（这类通常由
wait_timeout或interactive_timeout控制）
用 SHOW PROCESSLIST 排查积压请求时的关键点
它的价值不在“数多少”，而在“看什么卡住了”。重点关注 Time（秒）、State 和 Info 列：
- 筛选长时间运行的连接：
SHOW PROCESSLIST WHERE Time > 60（MySQL 5.7+ 支持 WHERE） -
State = 'Sending data'未必慢，但若持续超 30 秒，大概率是大结果集或磁盘 I/O 堵塞 -
State = 'Locked'或'Waiting for table metadata lock'表示 DDL 操作阻塞了查询，需优先处理 -
Info为空但State = 'Sleep'的连接，大概率是连接池未正确 close() 导致的泄漏
脚本化监控时别硬 parse SHOW PROCESSLIST 输出
它返回的是无结构文本，列宽动态变化，不同 MySQL 版本字段顺序可能不同（比如 8.0.28 加了 Progress 列）。真要自动化，请用：
-
SELECT COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND'（更稳定，但需开启 performance_schema） - 或直接读取
SHOW STATUS LIKE 'Threads_connected'的 Value 字段，一行 shell 就能提取：mysql -Nse "SHOW STATUS LIKE 'Threads_connected'" | awk '{print $2}' - 避免用
wc -l统计SHOW PROCESSLIST行数——头行、空行、权限截断都会导致误判
真正难的不是查出数字，而是区分“合理高连接”和“异常积压”：前者可能来自短连接峰值，后者往往伴随大量 Sleep 超时未释放，或少数几个 Query 卡死拖垮整个池。盯住 Threads_connected 和 Max_used_connections 的比值，再结合 SHOW PROCESSLIST 找出那几个“不动”的线程，问题基本就定位了。
