navicat 不支持原生脚本调度，需依赖操作系统任务计划调用其命令行工具执行sql；夜间检查应聚焦锁等待、慢查询堆积、连接数突变三类指标，并通过shell/powershell封装实现告警与日志。
Navicat 本身不支持原生脚本调度，得靠外部工具配合
Navicat 是图形化管理工具，不是运行环境——它没有内置定时器、无法直接执行 SELECT 后自动发告警或写日志。所谓“自动化脚本”，实际是用 Navicat 的「批处理作业」功能调用外部 SQL 文件，再依赖操作系统级任务计划（Windows Task Scheduler / macOS cron / Linux systemd timer）来触发。
常见误区是以为在 Navicat 里点几下就能“全自动夜间检查”，结果发现凌晨三点没跑、没报错也没日志，因为批处理作业只在 Navicat 客户端打开且登录状态下才可能执行（且不稳定）。
- 必须关闭 Navicat GUI 自动运行幻想，改用命令行方式调用
navicat.exe --run-sql（Windows）或navicatCLI（macOS/Linux，需确认版本是否支持） - SQL 脚本里避免使用 Navicat 特有语法（如
/*+ USE_INDEX(...) */注释），否则导出到命令行会报错 - 连接参数不能硬编码密码：用 Navicat 的「连接配置文件」+ 密码保存策略，或改用数据库原生认证方式（如 MySQL socket 认证、PostgreSQL .pgpass）
夜间健康检查 SQL 脚本该查什么，别贪多
夜间检查目标不是压测，而是捕获异常基线偏移。重点盯三类指标：锁等待、慢查询堆积、连接数突变。其他像表碎片率、索引未使用率等，建议周级人工跑一次即可。
以 MySQL 为例，一个轻量但有效的夜间检查脚本核心应包含：
-
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 300（查超 5 分钟未提交事务） -
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep' AND TIME > 60（查运行超 1 分钟的非空闲连接） -
SELECT VARIABLE_VALUE FROM performance_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Threads_connected'（对比历史均值，偏差 >30% 才告警） - 结尾加
SELECT NOW() AS check_time;，方便日志对齐时间戳
注意：PostgreSQL 需换用 pg_stat_activity 和 pg_locks；SQL Server 则依赖 sys.dm_exec_requests。别混用语法。
怎么让检查结果真正“被看到”，而不是堆在日志里
光执行 SQL 没用，关键是怎么把结果变成可响应的动作。Navicat 批处理作业本身不支持条件分支或邮件发送，所以必须在脚本外做一层封装。
- 用 PowerShell（Windows）或 Bash（Linux/macOS）包装 SQL 执行：先跑
navicat --run-sql ...，再用grep -q "trx_id"或awk '/Rows/{print $2}'提取关键字段 - 结果非空时，调用系统命令发邮件：
Send-MailMessage（PowerShell）或mail -s "DB Alert" admin@x.com - 日志路径必须绝对化，比如
C:\navicat_logs\nightly_check_$(date +%Y%m%d).log，避免 Navicat 工作目录切换导致写入失败
容易忽略的一点：Navicat 命令行执行失败时退出码是 1，但某些版本即使 SQL 报错也返回 0。务必在脚本里加 tail -n 1 log.txt | grep -q "ERROR" 做二次判断。
权限和连接稳定性比脚本逻辑更致命
夜间检查失败，90% 出在权限或网络上，而不是 SQL 写错了。
- 数据库账号必须有
PROCESS（MySQL）、pg_stat_activity视图 SELECT 权限（PostgreSQL），否则查不到活跃会话 - Navicat 连接配置里勾选了「自动重连」没用——命令行模式下不生效。得在脚本里加重试逻辑，比如用
for i in {1..3}; do navicat --run-sql ... && break || sleep 10; done - 如果数据库启用了 SSL，Navicat 连接配置里的 CA 证书路径在命令行下不会自动继承，必须显式传参或改用数据库原生命令行客户端（如
mysql -e "..."）替代
真正卡住人的，往往是某次数据库升级后 performance_schema 默认关闭，或者防火墙凌晨自动刷新策略，切断了定时任务所在机器的出站连接——这些和脚本本身一毛钱关系都没有，但会让你花两天排查。
