最准方式是执行show status like 'threads_connected'，它返回mysql当前维持的活跃tcp连接数（含sleep和query状态），瞬时准确、轻量无权限限制，且不截断、不锁表；而show processlist行数易受权限和默认100行限制影响，不适合统计。

直接查 Threads_connected 就是最准的当前连接数，不是 SHOW PROCESSLIST 的行数，也不是 Connections 累计值。

查当前连接数用 SHOW STATUS LIKE 'Threads_connected'

这条命令返回的是 MySQL 正在维持的、活跃的 TCP 连接数，是瞬时准确值：

• Threads_connected 是服务端视角的“活着的连接”，包括 Sleep 和 Query 状态，只要没断开就算
• 普通账号也能执行，不需要 SUPER 权限
• 结果和 SHOW PROCESSLIST 行数通常一致，但更轻量、不锁表、无截断（SHOW PROCESSLIST 默认只显示前 100 条）
• 注意别混淆 Threads_running——那是正在执行语句的连接数，一般远小于 Threads_connected

为什么不用 SHOW PROCESSLIST 数行数？

它看起来直观，但容易误判：

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

• 普通用户只能看到自己发起的连接，root 才能看到全量；权限不同，结果差异极大
• 默认只返回前 100 行，高并发场景下会漏掉大量连接（得加 FULL： SHOW FULL PROCESSLIST）
• 输出含大量字段（Info, State, Time），解析成本高，不适合脚本或监控采集
• 执行本身会短暂持有锁，在连接数极高时可能卡住或超时

max_connections 和 Max_used_connections 必须一起看

光知道当前连了多少没用，得结合上限和历史峰值判断风险：

• 查上限：SHOW VARIABLES LIKE 'max_connections'（比如返回 151 或 500）
• 查历史最高使用量：SHOW GLOBAL STATUS LIKE 'Max_used_connections'，这个值如果长期接近 max_connections，说明快到瓶颈了
• Max_used_connections 是自启动以来的最大值，不会自动归零；重启后重计，所以得结合 Uptime 看是否“刚启不久”
• 如果 Max_used_connections / max_connections > 0.8，建议查连接池配置或空闲连接泄漏

临时调大 max_connections 的坑

线上救急常用，但极易翻车：

• SET GLOBAL max_connections = 600 立刻生效，但 MySQL 重启就丢——容器环境尤其常见，重建后打回原形
• 必须有 SUPER 权限，普通应用账号执行报错：ERROR 1227 (42000): Access denied
• 如果报 ERROR 1238 (HY000): Variable 'max_connections' is a read only variable，说明启用了 --skip-grant-tables 或 read_only=ON
• 改完别忘了检查系统级限制：ulimit -n 至少要比新值高 20%，否则 MySQL 启动失败或连接被内核拒绝

真正要改上限，必须写进 /etc/my.cnf 的 [mysqld] 段并重启；云数据库（如阿里云 RDS）则只能走控制台参数模板——这些细节，一跳过去就是半夜告警。