Navicat 16 批处理任务无独立超时设置，超时由Socket Timeout、服务端wait_timeout/statement_timeout及ODBC Connect Timeout共同决定；须同步修改客户端Advanced页三项参数并调整服务端配置，且修改后需测试连接并重新启用任务。
Navicat 16 的自动化批处理任务本身**没有独立的“超时阈值”设置项**，它的执行耗时限制完全由底层连接参数和数据库服务端策略共同决定。调错地方只会白忙活。
为什么批处理任务会中途断开或卡死
自动任务不是在 Navicat 界面里跑的前台操作，它复用已建立的连接并静默执行 SQL 或备份动作。一旦连接因超时被关闭，任务就无法继续——但日志里常只显示“连接已关闭”或“Query timeout”，不提根源。
- Socket Timeout 默认 30 秒：执行一条 ALTER TABLE 或大 INSERT 时，Navicat 在等服务端返回结果，超时后直接断开连接，界面无响应
- MySQL 的
wait_timeout触发：比如设为 300 秒，任务中间空闲（如等待锁、解析 Excel）超过该值，服务端主动 KILL 连接 - PostgreSQL 的
statement_timeout优先级更高：即使 Navicat Socket Timeout 设到 600 秒，服务端仍可能在 30 秒后报query cancelled due to statement timeout - SQL Server ODBC 驱动隐含
Connect Timeout=30：Navicat 不暴露该参数，导致长查询还没开始就失败
必须改的三个连接参数（缺一不可）
所有修改都在「右键连接 → Edit Connection → Advanced」页完成：
-
Socket Timeout(sec)：填预期最长单次操作耗时的 1.5 倍。例如导出 500 万行预计 400 秒，这里填600；单位是纯数字秒，不能写600s -
KeepaliveInterval：必须小于服务端wait_timeout值的一半。先连上库执行SELECT @@wait_timeout;（MySQL）或SHOW statement_timeout;（PostgreSQL），再填对应值（如返回 600，则填240） - 勾选
Keep connection alive，且取消勾选Only send ping when there is a query：否则空闲时不发心跳，保活失效
服务端配套调整不能跳过
只改 Navicat 客户端参数，等于单方面努力：
- MySQL：在 Advanced 页的
Initial SQL框中填入SET SESSION wait_timeout = 28800;，确保每次连接建立后立即生效 - PostgreSQL：执行
ALTER DATABASE mydb SET statement_timeout = '600s';（需管理员权限），或对当前会话临时设SET statement_timeout = '600s'; - SQL Server：换用 JDBC 连接模式（而非默认 ODBC），或升级到 Navicat 17+，部分版本已支持显式配置驱动超时
- 通用检查：
max_allowed_packet（MySQL）、work_mem（PostgreSQL）不足也会表现为“连接重置”，不是超时问题，但现象高度相似
最易被忽略的是：批处理任务运行时不会重新初始化连接参数。哪怕你改完设置并保存了连接，已排队待执行的任务仍沿用旧连接上下文。务必在修改后手动触发一次「测试连接」，再重新注册/启用任务，否则新参数根本不会加载。
