navicat无独立“连接超时”开关，实际起效的是connection timeout（控制建连认证）、socket timeout（控制sql执行等待）和keepaliveinterval（需小于服务端wait_timeout的一半）三个参数。
navicat 本身没有“连接超时”这个独立开关，真正起作用的是三个互不干扰、但常被混用的超时参数：连接建立超时、socket读取超时、服务端空闲超时。设错任何一个，都会表现为“挂起”或“突然断开”。
为什么改了“连接超时”还是挂起？
Navicat 的「连接超时」（Connection Timeout）只控制从点击“连接”到完成 TCP 握手和身份认证的最长时间（默认 30 秒）。它不影响后续 SQL 执行过程中的等待——那是 Socket Timeout 和数据库服务端 wait_timeout 在管。
- 你执行一条大表 JOIN，卡住 2 分钟没反应？
Socket Timeout没调，它默认是 30 秒，超时后 Navicat 静默终止请求，界面卡死或报“连接已关闭” - 脚本跑一半断开，但网络明明通着？大概率是服务端
wait_timeout（比如 MySQL 默认 28800 秒）没被客户端心跳覆盖，中间空闲超时被 KILL - 连都连不上，提示“连接超时”，但 ping 得通？可能是防火墙拦截了三次握手后的 SSL 协商阶段，此时调高 Connection Timeout 无济于事
必须改的三个地方：Connection Timeout、Socket Timeout、KeepaliveInterval
三者要协同设置，不能只调一个：
-
Connection Timeout：设为 60～120 秒。仅用于初始建连，值太大反而掩盖真实网络或认证问题 -
Socket Timeout：在「高级」页中单独设置，单位秒。执行慢查询时靠它保命，建议设为预期最长查询耗时的 1.5 倍（如预计最慢语句 90 秒，这里填 135） -
KeepaliveInterval：关键！必须小于服务端wait_timeout值的 1/2。先连上库执行SELECT @@wait_timeout;确认真实值，再填（例如返回 60，则这里最大设 30）
PostgreSQL / SQL Server 用户注意驱动层超时
PostgreSQL 驱动（libpq）和 SQL Server 驱动（ODBC/JDBC）自身也有 socket 层超时逻辑，Navicat 的 Socket Timeout 可能被底层覆盖：
- PostgreSQL：若服务端设置了
statement_timeout（如ALTER DATABASE mydb SET statement_timeout = '120s';），它会强于 Navicat 设置，优先查SHOW statement_timeout; - SQL Server：ODBC 连接字符串里隐含
Connect Timeout=30，Navicat 不暴露该字段，只能靠升级驱动或换用 JDBC 模式绕过 - 所有场景下，
max_allowed_packet（MySQL）、work_mem（PostgreSQL）等服务端参数不足，也会导致大结果集传输中途静默失败，现象类似超时
批量修改连接配置避免逐个编辑
有几十个连接要调？别点开每个「编辑连接」——导出连接文件后直接文本替换更稳：
- 导出路径：
文件 → 导出连接，保存为 XML 文件 - 搜索替换：
Keepalive="false"→Keepalive="true"，KeepaliveInterval="240"→KeepaliveInterval="45"（按你服务端wait_timeout动态算） - 导入生效：
文件 → 导入连接，勾选“全部冲突运行此操作”
真正的坑不在数值本身，而在于你永远不知道哪个环节悄悄覆盖了它：云数据库强制缩窄 wait_timeout、旧版 Navicat 把 KeepaliveInterval 当毫秒处理、驱动自动重连时重置 socket 超时……调完记得用一个 5 分钟空闲 + 一条慢查询组合验证。
