Socket Timeout决定SQL执行等待时间，而非Connection Timeout；PostgreSQL中statement_timeout优先级更高；SQL Server的Connect Timeout需通过JDBC驱动或直连调整；MySQL需协同调整wait_timeout与KeepaliveInterval。
Socket Timeout 控制 SQL 执行等待时间
navicat 里真正决定“查询跑多久就中断”的参数是 socket timeout，不是 connection timeout，也不是界面里模糊标着“连接超时”的字段。它只管一条 sql 发出去后、等待返回结果的最长时间，默认值通常是 30 秒——所以你执行一个耗时 45 秒的聚合查询，就会静默中断，报错类似 connection lost 或 server has gone away。
实操路径：右键连接 → Edit Connection → 切换到 Advanced 页签 → 找到 Socket Timeout(sec) 输入框。
- 设为
120表示最长等 2 分钟，适合中等复杂度报表查询 - 设为
0表示不限时（不推荐，可能卡死界面） - 若值太小（如
5），简单 JOIN 都可能被误杀；太大（如600）则掩盖真实性能问题
PostgreSQL 用户注意 statement_timeout 优先级更高
PostgreSQL 驱动（libpq）自身有语句级超时控制，Navicat 的 Socket Timeout 在它面前会失效。只要服务端设置了 statement_timeout，比如执行过 ALTER DATABASE mydb SET statement_timeout = '90s';，那 Navicat 再怎么调高 Socket Timeout 也没用——查询在 90 秒时直接被 PostgreSQL 强制中止。
查当前生效值：SHOW statement_timeout;
- 返回
0表示未设限，此时 Navicat 的Socket Timeout才起作用 - 返回
90000表示 90 秒，这是毫秒单位，别看错 - 想临时绕过？新建查询窗口后先执行
SET LOCAL statement_timeout = '300000';（5 分钟）
SQL Server 的 Connect Timeout 不由 Navicat 暴露
SQL Server 连接字符串里自带 Connect Timeout=30（单位秒），这个参数 Navicat GUI 完全不提供修改入口。哪怕你在 Advanced 里把 Socket Timeout 设成 300，建连阶段仍会在 30 秒后失败，报错 Timeout expired。
- 唯一可靠办法：升级到 Navicat 最新版（17.2+），并切换连接模式为
JDBC（而非默认 ODBC），JDBC 驱动允许显式传入connectTimeout - 或者改用 IP 直连 + 关闭 Windows 防火墙的“保护模式”，减少握手延迟干扰
- 云上 SQL Server（如 Azure SQL）还受
login timeout限制，该值由服务端策略硬编码，客户端无法覆盖
MySQL 的 wait_timeout 会让 Socket Timeout 形同虚设
如果一条查询本身没超时，但执行完后空闲了 8 分钟（MySQL 默认 wait_timeout = 28800），再点下一条 SQL，Navicat 会复用旧连接句柄，结果立刻报 Lost connection——这时调大 Socket Timeout 毫无意义。
关键动作不是改客户端，而是协同：先查服务端真实值：SELECT @@wait_timeout;，再设 Navicat 的 KeepaliveInterval（必须 @@wait_timeout * 0.5），并勾选 Keepalive。
- 云数据库（如阿里云 RDS）通常锁死
wait_timeout为 300，此时KeepaliveInterval最大只能填149 -
Auto-reconnect要勾选，否则断连后手动点刷新才重连，脚本执行必然失败 - 事务未提交（
BEGIN后没COMMIT）会导致连接长期不空闲，wait_timeout不触发，但Socket Timeout仍对后续语句生效
实际配置永远不是单点调整，Socket Timeout 只是其中一环，而它的效果高度依赖服务端行为和网络中间设备。最容易被忽略的是：你调了客户端，却没确认服务端是否真按预期响应。
