max_used_connections是mysql启动以来瞬时并发连接的历史峰值，非当前连接数；当前连接数应查threads_connected，上限值查max_connections，三者需结合分析。
查 max_used_connections 看的是历史峰值，不是当前连接数
很多人一上来就执行 show variables like 'max_used_connections'，看到个数字就以为是“现在连着多少人”，其实完全不是。max_used_connections 是 mysql 自启动以来，瞬时并发连接数达到过的最高值，它不会自动归零，也不会实时更新成当前值。真正反映“此刻有多少连接”的是 threads_connected，得用 show status like 'threads_connected' 查。
常见错误现象：
– 重启 MySQL 后 Max_used_connections 变成 1 或 2，误以为系统很空闲
– 应用报“Too many connections”，但 Max_used_connections 还没到 max_connections，其实是当前连接已满，而峰值还没刷上去
– 把这个值当监控指标长期告警，结果一直不变化，失去预警意义
-
Max_used_connections只在 mysqld 启动后累加，服务不重启就不会重置 - 它不区分连接来源（应用、监控、DBA 临时登录都算），只要建立成功就计入
- 如果应用用了连接池且长期复用，这个值可能几个月都不变，但不代表没压力
SHOW STATUS 和 SHOW VARIABLES 别混用
SHOW VARIABLES 查的是配置项（比如 max_connections、wait_timeout），是“能设多大”；SHOW STATUS 查的是运行时状态（比如 Threads_connected、Aborted_connects），是“实际发生了什么”。Max_used_connections 是个特例：它被放在 SHOW VARIABLES 里返回，但语义上属于状态统计，不是可配置参数。
- 想确认当前连接上限：查
SHOW VARIABLES LIKE 'max_connections' - 想看当前活跃连接数：查
SHOW STATUS LIKE 'Threads_connected' - 想看历史最高并发：查
SHOW VARIABLES LIKE 'Max_used_connections'（注意大小写，MySQL 8.0+ 是Max_used_connections，5.7 是Max_used_connections，全小写也行但不推荐） - 所有这些命令都需有
PROCESS权限，普通应用账号通常没有，DBA 或监控账号才该配
用 SQL 查更可控，但要注意权限和性能影响
比起客户端执行 SHOW 命令，用标准 SQL 查 performance_schema 表可以拿到更细粒度的信息，比如按用户、主机、命令类型拆分连接数。不过代价是：默认 MySQL 5.7+ 的 performance_schema 不一定开启全部消费者，而且查 threads 表本身会轻微增加开销。
- 最轻量的实时查询：
SELECT COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_STATE IS NOT NULL;
- 要过滤掉 sleep 连接（即空闲但未断开的）：
SELECT COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_STATE != 'Sleep';
- 检查是否启用：
SELECT * FROM performance_schema.setup_consumers WHERE NAME = 'events_statements_current';，若ENABLED = 'NO'，部分表可能为空 - 线上高并发库慎用
SELECT * FROM performance_schema.threads，容易触发锁或慢查询，优先用带COUNT(*)的聚合查询
监控时别只盯一个值，三个数要一起看
单看 Max_used_connections 没法判断瓶颈。真正有用的是三者关系：Threads_connected（当前）、Max_used_connections（历史峰值）、max_connections（上限）。比如 Threads_connected 长期在 200，Max_used_connections 是 210，max_connections 是 250 —— 表明还有缓冲，但已接近临界；如果 Threads_connected 突然跳到 249 并卡住，那大概率是连接池泄漏或慢查询堆积。
- 定期采样建议间隔 ≥ 10 秒，太密会加重
performance_schema负担 - 注意
max_connections修改后要重启或动态生效（5.7+ 支持SET GLOBAL max_connections = N），但Max_used_connections不会因此重置 - 有些云数据库（如阿里云 RDS）会把
Max_used_connections包装成监控指标名MySQL_MaxUsedConnections，底层还是读同一个变量，但展示逻辑可能做平滑处理，和直连 mysqld 查到的原始值略有差异
真正难的不是查出这三个数，而是发现 Threads_connected 在缓慢上涨却不回落，或者 Aborted_connects 持续增加 —— 那说明连接没被正确释放，或认证频繁失败。这种问题藏在日志和代码里，不在状态变量表面。
