Linux版Navicat无“连接超时”滑块，真正起效的是Connection Timeout（建连阶段）、Socket Timeout（SQL执行中）、KeepaliveInterval（空闲心跳）三参数协同，且须开启Reconnect when connection is lost；单设任一均无效。
Linux 版 Navicat 没有“连接超时”滑块，也不能靠定时 SQL 脚本保活——真正起效的是三组协同参数：Connection Timeout（建连阶段）、Socket Timeout（SQL 执行中）、KeepaliveInterval（空闲心跳），再叠加 Reconnect when connection is lost 开关。单设任一都不够。
Connection Timeout 和 Socket Timeout 怎么填才不卡死
这两个值常被混用，但作用阶段完全不同：
-
Connection Timeout：只管“点连接按钮后到认证成功”的最大等待时间，默认 30 秒。若你数据库在云上、走 SSH 隧道或 DNS 解析慢，可设为60～120；设太大反而掩盖真实网络问题 -
Socket Timeout：在「高级」页单独配置，单位秒，控制执行一条 SQL 后等待返回的上限。比如导出大表或跑聚合查询，预期最长耗时 150 秒，这里就填240（1.5 倍）；低于这个值会静默中断，界面卡住或报“连接已关闭” - PostgreSQL 用户注意：
statement_timeout（服务端设置）会强于 Navicat 的Socket Timeout，执行SHOW statement_timeout;确认是否已被覆盖 - SQL Server 用户注意：ODBC 驱动自带
Connect Timeout=30，Navicat 不暴露该字段，升级驱动或换 JDBC 模式更可控
KeepaliveInterval 必须小于 wait_timeout 的一半
这是防掉线最常踩坑的一环。Navicat 的心跳不是“越勤越好”，而是必须和数据库服务端节奏对齐：
- 先连上库，执行
SELECT @@wait_timeout;（MySQL）或SHOW VARIABLES LIKE 'wait_timeout';，记下返回值（云数据库常见为300） -
KeepaliveInterval必须严格小于该值的 0.5 倍：如返回300，最大只能设149，推荐120或180；设成300就等于没设 - 务必勾选
Keepalive（启用 TCP 层保活），否则仅靠应用层心跳，NAT/防火墙仍可能回收连接 - 取消勾选
仅当有查询时发送ping——否则空闲时完全不发包，心跳形同虚设
自动重连（Reconnect）不是万能的，但必须开
勾选 Reconnect when connection is lost 是应对“连接已死但客户端未感知”的最后一道防线，但它不替代心跳：
- 它只在 Navicat 主动发 SQL 时检测失败并重试，不会后台轮询连接状态
- 对长事务未提交、全表扫描卡住等“非空闲态断连”无效，这类场景需拆分 SQL 或加索引
- SSH 隧道用户：必须同时在 Navicat 的 SSH 配置页勾选
Keep alive并设为30，且跳板机/etc/ssh/sshd_config中配ClientAliveInterval 30和ClientAliveCountMax 3 - 云数据库用户：查清平台文档里的“连接空闲超时”（如阿里云 RDS 明确写 300 秒），若该值比你的
KeepaliveInterval还小，那心跳根本发不出去，只能靠自动重连 + 缩短单次操作粒度
批量修改连接配置避免逐个编辑
几十个连接手动改容易漏，导出 XML 文件批量处理最稳：
- 文件 → 导出连接（注意先点左上角“对象”再导出，否则导出的是查询结果）
- 用文本编辑器打开导出的
.xml，全局替换：Keepalive="false" KeepaliveInterval="240"→Keepalive="true" KeepaliveInterval="120" - 再补一行：
Reconnect="true"（若原文件无此字段，加在<Connection>标签下任意位置） - 文件 → 导入连接 → 全部冲突运行“替换”，完成
最容易被忽略的是：Linux 版 Navicat 不继承系统 DNS 缓存，如果连接用域名而非 IP，而 /etc/resolv.conf 里 DNS 响应慢，首次建连就会卡在 Connection Timeout 阶段——建议生产环境一律填 IP 地址。
