最准、最轻量的方式是执行 SHOW STATUS LIKE 'Threads_connected';，它实时返回当前已建立的TCP连接总数（含Sleep和活跃状态），与SHOW PROCESSLIST行数一致但更轻量，且不受权限限制影响计数准确性。
直接执行 SHOW STATUS LIKE 'Threads_connected'; 就能拿到当前真实连接数，这是最准、最轻量的方式。
怎么快速查出当前连了多少个？
别翻配置、别猜日志，就一条命令：SHOW STATUS LIKE 'Threads_connected';。它返回的是此刻已建立的 TCP 连接总数（含 Sleep 和活跃状态），不是近似值，也不是采样结果。
- 返回值为 0 表示没客户端连上来，但 MySQL 服务本身仍在运行
- 这个值会随应用建连/断连实时跳变，比如你刚执行完一条查询又立刻断开，它可能从 1 变回 0
- 和
SHOW PROCESSLIST的行数一致，但比后者更轻——不触发权限校验、不扫描线程栈、不拼 SQL 字符串 - 如果用监控脚本轮询，建议间隔 ≥ 5 秒，避免频繁调用造成额外线程开销
为什么 SHOW PROCESSLIST 看到的行数有时对不上？
因为默认只返回前 100 行，且普通用户只能看到自己发起的连接。哪怕 Threads_connected 是 200，你没 PROCESS 权限时也大概率只看到几十行。
- 加
FULL关键字：SHOW FULL PROCESSLIST;才能避免 SQL 截断，但需PROCESS权限 - 没权限时可用：
SELECT COUNT(*) FROM information_schema.PROCESSLIST;，它对非自身会话的INFO列返回 NULL，但计数准确 - 注意：
information_schema.PROCESSLIST是只读视图，不能加WHERE TIME > 60做条件过滤优化，大数据量下查询会稍慢
Threads_running 和 Threads_connected 有什么区别？
前者才是你该盯紧的真实负载指标——它只统计正在执行 SQL 或处理请求的线程数，Sleep 状态的连接不计入。
- 比如
Threads_connected = 120，但Threads_running = 3，说明大部分是空闲连接池，实际压力很小 - 如果
Threads_running长期接近max_connections的 30% 以上，就要查慢查询或锁等待了 - 这两个值都能用
SHOW STATUS LIKE 'Threads%';一次性查出来，比分别执行两次更省事
查完连接数后最容易忽略的一件事
光看数字没用，得结合 Max_used_connections 和服务器资源一起判断。比如 Threads_connected 当前是 80，但 Max_used_connections 是 499，说明历史峰值快撞上限了，而你还没意识到连接池配置可能早该调了。
