Navicat本身不支持自动监测连接数溢出，需依赖Navicat Monitor实现自动化监控；其仅能手动执行SHOW VARIABLES和SHOW STATUS语句临时诊断，无法定时告警或趋势分析。
Navicat本身不支持自动监测连接数溢出
navicat是数据库管理工具，不是监控系统，它没有内置的实时阈值告警、历史趋势分析或后台轮询能力。所谓“配置自动化脚本监测连接数溢出”，实际要分两层理解：一是用navicat执行一次性的检查语句；二是把真正的监控任务交给 navicat monitor ——这才是官方定位为“无代理远程监控”的专用组件。
用Navicat手动查当前连接数（临时诊断用）
如果你只是想快速确认是否已达到 max_connections 上限，可在Navicat中新建查询并运行：
SHOW VARIABLES LIKE 'max_connections'; SHOW STATUS LIKE 'Threads_connected';
注意这两个值的对比关系：Threads_connected 接近或等于 max_connections 时，新连接就会被拒绝。但这个操作不会自动触发通知，也不能定时执行——每次都要人工点开、粘贴、运行。
- 别依赖“查询结果集限制”来防溢出，它只控制Navicat本地显示行数，不影响服务端连接计数
- MySQL 8.0+ 用户需留意
caching_sha2_password认证插件可能让部分连接卡在认证阶段，表现为Threads_connected持续升高但无活跃查询 - 执行
SHOW PROCESSLIST可识别长连接、Sleep状态连接，但Navicat默认只显示前100条，需加LIMIT或改用命令行补全
真正实现自动化监测必须用 Navicat Monitor
Navicat Monitor 才是解决“连接数溢出”这类问题的正确工具。它通过SSH或SNMP定期采集指标，支持自定义阈值告警，并能邮件/Slack通知。配置路径如下：
- 安装
Navicat Monitor到任意一台可访问数据库的机器（无需在数据库服务器上装任何代理） - 添加目标实例时，在“高级设置”中启用
Threads_connected指标采集（默认已开启） - 进入“警报”→“新建警报”，选择指标为
Threads_connected，设置条件如：大于 95% of max_connections，持续时间 > 2分钟 - 保存后，它会每30秒检查一次，超限时立即发通知，同时记录到历史图表中供回溯
关键点在于：Navicat Monitor 的存储库（repository）必须用独立数据库（如另一台MySQL实例），不能复用被监控库本身——否则连接数爆满时，连告警存储都写不进去。
容易被忽略的兼容性细节
很多用户配完 Navicat Monitor 却收不到告警，问题常出在三个地方：
- 云数据库（如阿里云RDS、AWS RDS）默认屏蔽
SHOW PROCESSLIST和部分STATUS变量，需在控制台开启“性能详情”或“增强监控”开关 - MySQL配置中若设置了
skip-show-database，Navicat Monitor将无法读取库级指标，需移除该参数并重启 - 使用LDAP/AD集成认证时，
Navicat Monitor的监控账号必须有SELECT权限访问performance_schema.threads表（MySQL 5.7+）或information_schema.PROCESSLIST（旧版）
连接数问题从来不是孤立现象，它往往和慢查询堆积、未关闭的事务、应用层连接池泄漏强相关。只盯 Threads_connected 数值而不看 Slow_queries 或 Innodb_row_lock_waits，等于只处理症状。
