Navicat自动任务“连接超时”本质是已建立连接被中间设备或MySQL主动关闭后未及时感知，需同步配置SSH心跳、MySQL wait_timeout和Navicat自动重连，并避免长事务、全表扫描等隐性断连SQL。
navicat 自动任务日志里出现“连接超时”，基本可以排除网络中断或服务宕机，真正的问题往往藏在任务执行过程中的连接状态管理上——它不是连不上，而是连着连着就断了。
自动任务里“连接超时”和普通连接超时不是一回事
普通连接超时发生在建连阶段（比如填错 host 或端口），而自动任务里的超时，几乎都发生在任务已运行数秒甚至数分钟后。此时 Navicat 仍认为连接“活着”，但底层 TCP 连接已被中间设备（SSH 隧道、云 NAT、防火墙）或 MySQL 的 wait_timeout 主动关闭。任务继续往这个失效连接发 SQL，就会报错：
Lost connection to MySQL server during queryMySQL server has gone away- 或直接卡住几秒后提示“Query timeout”
关键点：自动任务默认复用连接，不会像手动查询那样在每次执行前做健康检查。
必须同步调 SSH 心跳、数据库超时、Navicat 自动重连
只改其中一项，大概率白忙活。三者缺一不可：
- 如果走 SSH 隧道：在 Navicat 的 SSH 配置页勾选
Keep alive，设为30秒；同时确保跳板机的/etc/ssh/sshd_config含ClientAliveInterval 30和ClientAliveCountMax 3，并重启sshd - 直连 MySQL：登录后立即执行
SET SESSION wait_timeout = 28800000（3 小时），或全局设SET GLOBAL wait_timeout = 28800000（需 SUPER 权限） - Navicat 侧：编辑连接 → “高级” → 勾选
Reconnect when connection is lost；别只依赖“保持连接间隔”，它只发SELECT 1，不解决连接已死但客户端没感知的问题
自动任务 SQL 本身容易触发隐性断连
某些写法会让连接长时间空转或卡在非空闲态，导致心跳无效、自动重连不触发：
- 大事务未提交：
BEGIN; UPDATE ...; -- 忘记 COMMIT→ 连接持续占用，wait_timeout不生效，但会被服务端KILL - 全表扫描类语句：执行计划显示
type=ALL、rows百万级 → 占用连接时间过长，中间链路先断 - 无 LIMIT 的 DELETE/UPDATE：例如
DELETE FROM logs WHERE created_at < '2024-01-01'→ 建议拆成WHERE id BETWEEN ? AND ? LIMIT 10000分批执行 - ORDER BY + LIMIT 无覆盖索引：比如
ORDER BY status, created_at LIMIT 20却只有status单列索引 → 触发Using filesort，拖慢执行时间
云数据库环境下最容易被忽略的细节
阿里云 RDS、腾讯云 CDB 等通常禁止修改 wait_timeout，此时仅靠 Navicat 设置毫无意义。必须：
- 查清服务端实际值：
SHOW VARIABLES LIKE 'wait_timeout';（常见为300秒） - Navicat 的“保持连接间隔”设为比它小
60秒（如240），且务必启用Reconnect when connection is lost - 避免在自动任务里跑长事务；所有 DML 操作后紧跟
COMMIT或ROLLBACK - 若任务含跨库 JOIN 或子查询，优先在数据库内建临时表或物化中间结果，减少客户端与服务端往返
真正难处理的，是那种“连接看似正常，但执行到第 3 分钟突然断”的情况——它往往意味着某条 SQL 正在锁表、等资源，或被中间层静默回收。这时候看日志不如直接开一个新查询窗口，手动 KILL 对应线程再重试任务。
