navicat 不支持生产级定时监控和自动预警,其计划任务仅限本地执行sql脚本;应启用文件型慢查询日志,配合外部脚本轮询解析并告警,navicat仅作人工复核终端。
navicat 本身不支持生产级定时监控和自动预警
navicat 是一个数据库 gui 工具,它的「计划任务」功能仅限于本地 windows/macos 系统上触发 sql 脚本执行,且依赖客户端常驻运行、系统登录态、任务计划程序(如 windows task scheduler)配合。它无法:主动监听 mysql 的 slow_query_log、解析日志内容、做阈值判断、发送企业微信/钉钉/邮件等告警——这些是运维监控系统的职责,不是 navicat 的设计目标。
真正可行的替代方案:用 MySQL 原生慢日志 + 外部脚本轮询
生产环境应放弃“用 Navicat 定时查 slow_log 表”这类不可靠路径(mysql.slow_log 表默认关闭,且写入性能差、无索引、不保留原始 SQL 上下文)。推荐组合:
- 开启 MySQL 的文件型慢查询日志:
slow_query_log = ON,slow_query_log_file = /var/log/mysql/mysql-slow.log - 设置合理阈值:
long_query_time = 1.0(单位秒,建议从 1 开始,避免日志爆炸) - 用轻量脚本(Python/Shell)每分钟 tail -n 1000 日志,匹配
# Time:和# Query_time:行,提取超时 SQL 及耗时 - 命中阈值后,调用
curl推送至钉钉机器人 Webhook 或写入告警队列
如果非要绑定 Navicat,唯一能做的只是「手动验证环节」
Navicat 在这个流程里只适合当「人工复核终端」,比如:
- 收到告警后,在 Navicat 中粘贴告警里的 SQL,用
EXPLAIN FORMAT=JSON查看执行计划 - 连接到对应库,执行
SHOW PROCESSLIST看是否仍有阻塞查询 - 用 Navicat 的「数据同步」或「结构同步」辅助修复索引缺失(如发现
type: ALL且key: NULL)
注意:mysql.slow_log 表即使开启,也默认无索引,SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10 在日志量大时会严重拖慢 Navicat 响应,别把它当实时监控源。
容易被忽略的关键点:日志权限与滚动策略
MySQL 慢日志文件由 mysqld 进程用户(如 mysql)写入,外部脚本读取时必须有读权限;否则 cron 执行会静默失败。同时必须配置 logrotate,否则单个日志文件可能撑爆磁盘:
/var/log/mysql/mysql-slow.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 640 mysql mysql
sharedscripts
postrotate
if [ -f /var/run/mysqld/mysqld.pid ]; then
kill -USR1 `cat /var/run/mysqld/mysqld.pid`
fi
endscript
}
没配 postrotate 里的 kill -USR1,MySQL 就不会重新打开新日志文件,导致 logrotate 失效。











