不能只看Threads_connected当前值，因其瞬时波动易致误报，需结合趋势分析（如连续6次采样递增且≥max_connections×0.85）与多指标关联（Aborted_connects、Threads_created）识别连接泄漏。
为什么不能只看 Threads_connected 当前值
Threads_connected 是 mysql 实时连接数，但告警不能只比对 Threads_connected >= max_connections - 5 这种静态阈值。真实场景中，短时脉冲（如应用启动、定时任务）会瞬间拉高连接数，又快速回落，误报率极高；而真正的连接泄漏往往表现为缓慢、持续的爬升，需要识别趋势而非瞬时值。
用 SHOW GLOBAL STATUS + 持续采样识别缓慢增长
必须基于至少 2 分钟以上的周期性采集（比如每 10 秒查一次），再计算斜率或环比变化率。直接读取 SHOW GLOBAL STATUS LIKE 'Threads_connected' 即可，无需额外表或插件。
- 推荐用脚本（python / bash）调用
mysql -N -s -e "SHOW GLOBAL STATUS LIKE 'Threads_connected'"，提取第二列数值 - 连续 6 次采样（即 1 分钟内），若每次值都 ≥ 前一次，且最新值 ≥
max_connections * 0.85，才触发初步预警 - 避免用
information_schema.PROCEsslIST计数——它不包含 sleep 状态连接，且性能开销大，和Threads_connected统计口径不一致
如何获取准确的 max_connections 值
MySQL 的 max_connections 可能被动态修改，也可能由配置文件设定，还可能受操作系统限制（如 open_files_limit）隐式约束。仅查 select @@max_connections 不够可靠。
- 运行
SELECT @@max_connections, @@global.max_connections，两者应一致；若不一致，说明会话级被覆盖过，需查SHOW VARIABLES LIKE 'max_connections' - 检查错误日志是否出现
Too many connections，这说明实际已达硬上限，此时Threads_connected可能已卡在max_connections不再上涨，但新连接全被拒绝 - 用
mysqld --verbose --help | grep "max-connections"确认编译默认值，排除配置未生效的情况
告警阈值建议与抑制逻辑
硬设 “剩余 5 个连接” 很危险：小实例（max_connections = 100）和大实例（max_connections = 2000）敏感度完全不同。应该用比例 + 绝对值双条件。
- 触发告警需同时满足：
Threads_connected >= max_connections * 0.9且Threads_connected >= 150 - 若 5 分钟内重复触发同一实例的该告警，自动降级为“通知”而非“严重”，避免雪崩式告警轰炸
- 务必排除监控自身连接：在采集脚本里加
--defaults-file=/etc/mysql/monitor.cnf，其中monitor.cnf显式指定user=monitor，并在 MySQL 中限制该账号只能执行SHOW GLOBAL STATUS，避免监控连接计入统计
真正难的是区分“健康高峰”和“泄漏前兆”——前者有明确业务上下文（如凌晨批量导入），后者常伴随 Aborted_connects 上升或 Threads_created 持续增加。光盯 Threads_connected 就像只看体温不管咳嗽，得把几个指标串起来看。