navicat不支持用“自动运行”任务保活连接，真正有效的是连接级配置：编辑连接→高级→勾选“保持连接活跃”，设间隔60秒并取消“仅当有查询时发送ping”。
navicat 本身没有“自动运行脚本保持连接活跃”的功能——保活靠的是连接级配置，不是靠定时执行 sql 脚本。试图用「自动运行」任务（比如每分钟跑 select 1）来维持连接，不仅无效，还可能触发数据库的连接数限制或审计告警。
为什么“自动运行 SQL”不能替代连接保活
Navicat 的「自动运行」是应用层任务调度，依赖客户端前台运行、进程存活、GUI 响应。一旦窗口最小化、系统锁屏、用户切到其他应用，任务就大概率挂起；更不用说关机、休眠、远程桌面断连等场景。它不干预 TCP 连接状态，对 NAT 网关、云负载均衡器、数据库 wait_timeout 等导致的空闲断连完全无感。
- 常见现象：
Failed to load job: Permission denied或任务列表显示“已运行”但日志为空 - 即使任务真执行了，
SELECT 1这类语句只在查询发起瞬间建立新连接（如果连接池未复用），无法维持原有长连接 - 频繁执行还会增加数据库解析开销，尤其当同步任务本身已在跑时，容易引发锁竞争
真正有效的保活设置：编辑连接 → 高级 → 保持连接活跃
这是唯一被 Navicat 官方支持且实测稳定的方案，作用于 TCP 层，与任务调度无关。
- 右键目标连接 → 「编辑连接」→ 切换到「高级」选项卡
- 勾选
保持连接活跃 - 将
每隔(秒)发送一个ping包设为60（不可 >300，否则仍被中间设备回收） - 务必取消勾选
仅当有查询时发送ping——否则空闲时照样断 - 该设置只影响当前连接，本地直连 MySQL（localhost）通常无需开启
配合数据库端调优才能彻底防断连
Navicat 保活只是单方面努力。若数据库服务端主动 kill 空闲连接，客户端再怎么 ping 也白搭。
- MySQL 检查：
SHOW VARIABLES LIKE 'wait_timeout';，建议设为 ≥ 28800（8 小时） - PostgreSQL 检查：
SHOW tcp_keepalives_idle;，若为 0，需在postgresql.conf中显式设为 60 - 云数据库（如阿里云 RDS、腾讯云 CDB）请确认控制台中「连接空闲超时时间」是否 ≥ 60 秒
- 防火墙/NAT 设备若有会话超时策略（常见 5~15 分钟），Navicat 的 60 秒 ping 是唯一能绕过的手段
保活的关键不在“运行什么”，而在“怎么连”。很多人花几小时写定时 SQL 脚本，却漏掉连接属性里那个没勾上的 保持连接活跃 复选框——这才是最常被忽略、又最立竿见影的一处。
