最准方式是执行select count(*) from information_schema.processlist where command != 'sleep'，该语句过滤sleep状态，精准统计正在执行sql的真实活跃连接数。
MySQL怎么查当前活跃连接数
直接查 information_schema.PROCESSLIST 表最可靠，但要注意权限和实时性。普通用户可能没权限访问该表，DBA 账号执行才稳定。
常用语句是：
SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep';
这里过滤掉 Sleep 状态，只统计真正干活的连接（比如执行查询、插入、事务中的连接）。如果想看全部连接（含空闲），去掉 WHERE 条件即可。
-
COMMAND字段值为Sleep表示线程已建立但没在执行语句，属于空闲连接 - 某些监控场景需要区分“总连接数”和“活跃连接数”，不能只看
COUNT(*)不加条件 - 该查询本身会新建一个连接并短暂占用资源，高并发下频繁执行可能轻微拖慢元数据响应
PostgreSQL 怎么用 pg_stat_activity 查连接数
PostgreSQL 没有 PROCESSLIST，对应的是 pg_stat_activity 视图，状态字段叫 state，不是 COMMAND。
查非空闲连接：
SELECT COUNT(*) FROM pg_stat_activity WHERE state = 'active';
注意：state 取值包括 active、idle、idle in transaction 等，idle in transaction 表示事务已开启但没提交，也应纳入“需关注的连接”范畴。
- 普通用户默认只能看到自己的行，要查全部需具备
pg_read_all_stats角色权限 -
backend_start和state_change字段可辅助判断连接是否异常老化 - 不要依赖
pid数量做连接池上限判断——有些连接可能是刚断开还没被回收（状态为disabled或已消失）
SQL Server 的 sys.dm_exec_sessions 查询要点
SQL Server 用动态管理视图 sys.dm_exec_sessions，但要注意它只返回当前用户可见的会话，默认不包含系统会话；如需完整统计，得加 IS_SRVROLEMEMBER('sysadmin') = 1 判断或用 SA 权限执行。
查用户连接数（排除系统会话）：
SELECT COUNT(*) FROM sys.dm_exec_sessions WHERE is_user_process = 1;
若还要排除空闲连接，可追加：
AND status = 'running'
不过更实用的是结合 sys.dm_exec_requests 判断是否有正在运行的请求。
-
status为sleeping不代表连接无效，可能是等待新请求的连接池连接 - 连接数突增时，建议连带查
login_name和host_name，快速定位来源应用 - 该 DMV 不记录已断开但尚未清理的连接，所以数值略低于实际 TCP 连接数是正常的
为什么 COUNT(\*) 有时不准？几个典型陷阱
不是语法错，而是语义理解偏差导致结果不符合预期。比如 MySQL 中 SHOW STATUS LIKE 'Threads_connected' 返回的是当前打开的连接总数，而 SELECT COUNT(*) FROM PROCESSLIST 在某些版本里可能漏掉刚创建还未完全初始化的连接。
- 不同数据库对“连接”的定义不同：有的算 TCP 层，有的算会话层，有的还区分登录态与执行态
- 查询系统表本身需要一定时间，高并发下两次执行之间连接可能已新建或关闭，结果天然有抖动
- 某些中间件（如 ProxySQL、MaxScale）或连接池（如 HikariCP）会在后端复用连接，前端看到的“连接数”和后端实际数量不一致
- 权限不足时查询返回空结果集，
COUNT(*)得到 0，容易误判为“无连接”
真要监控，别只靠单次 COUNT(*)，得结合状态字段、时间窗口聚合、以及外部指标（如 netstat 统计 ESTABLISHED 状态的 mysqld 端口连接数）交叉验证。
