show status 的 threads_connected 是瞬时快照且含空闲连接，而 show processlist 实时显示活跃会话；threads_running 才反映真实并发压力，aborted_connects/clients 突增更需优先排查。
show status 返回的连接数为什么和 show processlist 不一致
因为 show status 里像 threads_connected 这类指标是快照值，反映的是语句执行那一刻的瞬时连接数；而 show processlist 是实时抓取当前活跃会话列表，如果连接刚建立又快速断开（比如短连接应用），show status 可能还来不及更新，或者已被复用进连接池。更关键的是：threads_connected 包含空闲连接，threads_running 才代表真正正在执行 sql 的线程。
实操建议：
- 查真实并发压力看
Threads_running，不是Threads_connected - 怀疑连接泄漏时，对比
SHOW STATUS LIKE 'Threads_%'和SHOW PROCESSLIST输出行数，若前者远大于后者，说明大量连接卡在 sleep 状态没释放 -
SHOW PROCESSLIST默认只显示当前用户能看到的连接，加root权限或启用performance_schema才能看全
哪些 STATUS 变量真正反映连接健康度
不是所有以 Threads_ 开头的变量都管用。真正值得盯的就三个：
-
Threads_connected：当前打开的连接总数（包括 sleep 和 active） -
Threads_running：正在执行语句的连接数（高了说明 CPU/IO 压力大） -
Threads_created：自实例启动以来创建过多少新连接（持续上涨 +Threads_connected居高不下 = 连接未复用）
注意：Aborted_connects 和 Aborted_clients 虽不属于“连接数”，但直接暴露连接异常——前者是客户端连不上（密码错、max_connections 满），后者是客户端非正常断开（超时、网络中断）。这两个值突增，比连接数本身更值得优先排查。
SHOW STATUS LIKE '%connect%' 查不到想要的变量怎么办
MySQL 8.0+ 默认关闭部分状态变量统计（尤其 performance_schema 相关），且 LIKE 模糊匹配对大小写敏感，'%connect%' 不会匹配到 Threads_connected（中间是下划线，不是 “connect” 字串）。
- 必须用准确前缀：
SHOW STATUS LIKE 'Threads%'或SHOW STATUS LIKE 'Aborted%' - 确认变量是否启用：某些变量如
Connection_errors_%需要开启performance_schema并配置对应 consumers 才有数据 - 别依赖 GUI 工具的搜索框——很多客户端对
SHOW STATUS结果做过滤或截断，直接走命令行最可靠
用 SELECT 查询 performance_schema 代替 SHOW STATUS 更准吗
更准，但代价是多一层间接性。例如 SELECT COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' 等价于 Threads_connected，但能进一步筛选 PROCESSLIST_STATE = 'Sleep' 或 PROCESSLIST_INFO IS NOT NULL。
- 优势：可关联
accounts、events_statements_summary_by_thread_by_event_name查具体哪个用户/线程在耗资源 - 坑点：
performance_schema默认不采集所有事件，setup_consumers里得开events_statements_current和events_waits_current才能看到 SQL 和锁等待 - 性能影响：高频查询
performance_schema表可能拖慢实例，生产环境慎用SELECT * FROM threads
连接状态这事儿，变量名容易记混，Threads_connected 和 Threads_created 就差一个词，但意义天壤之别；更麻烦的是，很多监控脚本直接抓 SHOW STATUS 输出，却没校验字段是否存在——MySQL 升级后变量名微调（比如 5.7 到 8.0），脚本就 silently 失效。
