navicat连接postgresql 14查询超时需同步配置三处：socket timeout（客户端）、statement_timeout（服务端）和keepaliveinterval（保活），任一缺失都会导致查询卡死或静默断开。
Navicat 连接 PostgreSQL 14 执行查询超时，不能只调 Navicat 的“连接超时”——它只管建连，不管 SQL 执行卡住。真正起作用的是三处：Navicat 的 Socket Timeout、PostgreSQL 服务端的 statement_timeout、以及底层连接空闲保活参数 KeepaliveInterval。设错任何一个，都会表现为“执行到一半卡死”“查大表没反应”或“隔两分钟突然断开”。
Socket Timeout 必须显式设置（否则默认 30 秒）
Navicat 的「连接超时」（Connection Timeout）对慢查询完全无效；真正控制 SQL 执行等待的是「Socket Timeout」，但它在界面里藏得深，且默认不启用。
- 进入连接属性 → 「高级」页 → 勾选
Use socket timeout，填入合理值（如预期最长查询耗时的 1.5 倍，90 秒查询建议填135） - 该值单位是秒，不是毫秒；填
0表示禁用，但不推荐——会失去对失控查询的主动终止能力 - 注意：若 PostgreSQL 已设了
statement_timeout（见下一条），Socket Timeout会与之叠加生效，但以先触发者为准 - PostgreSQL 驱动（libpq）自身也有 socket 层超时，若你用的是旧版 Navicat 或自定义驱动，
Socket Timeout可能被底层覆盖，此时需优先确认服务端配置
statement_timeout 是更可靠的兜底机制
比起客户端参数，直接在 PostgreSQL 侧设 statement_timeout 更稳定、更易审计，且对所有客户端（psql、DBeaver、应用代码）一视同仁。
- 在 Navicat 中执行：
ALTER DATABASE mydb SET statement_timeout = '120s';（对整个库生效） - 或按用户设：
ALTER ROLE myuser SET statement_timeout = '300s';（仅影响该用户连接） - 验证是否生效：
SHOW statement_timeout;，返回值应为120s或类似格式 - 注意：该设置需在连接建立后才加载，新连接立即生效；已有连接需重连，或手动执行
SET statement_timeout = '120s'; - 云数据库（如 AWS RDS、阿里云 PolarDB）通常已预设该值，改前先
SHOW确认，避免被强制覆盖
KeepaliveInterval 不配好，查询中途也会静默断开
即使 SQL 在跑，连接空闲超过服务端 wait_timeout（PostgreSQL 实际叫 tcp_keepalives_idle，但行为由内核+服务端共同决定），连接会被服务端 KILL，现象就是“查着查着断了”，错误常为 server closed the connection unexpectedly。
- 先查服务端真实空闲超时值：
SELECT current_setting('tcp_keepalives_idle');（注意：PostgreSQL 不暴露 wait_timeout，实际依赖系统级 TCP keepalive +tcp_keepalives_*参数） - 在 Navicat 连接属性 → 「高级」页 → 填
KeepaliveInterval，建议设为系统tcp_keepalives_idle值的 1/2（如查出是7200，这里填3600） - 该值单位是秒；必须小于服务端空闲阈值，否则心跳发不出去，等于没设
- Linux 上还需确认内核参数：
cat /proc/sys/net/ipv4/tcp_keepalive_time，若远小于 PostgreSQL 设置，Navicat 的KeepaliveInterval可能被系统截断
最容易被忽略的点：这三个参数不是独立生效的。比如你把 Socket Timeout 设成 300 秒，但 statement_timeout 是 60 秒，那查询 61 秒就会被 PostgreSQL 主动中止，Navicat 收到的是服务端错误而非超时提示；反过来，若只设了 statement_timeout 却没配 KeepaliveInterval，长查询中间空闲几秒就可能断连。调参前务必先用 SELECT pg_sleep(120); 模拟慢查询，观察断在哪一环。
