socket timeout是唯一能拦住慢sql的客户端参数，控制等待服务端返回结果的最长时间，默认30秒，需设为预期最长查询耗时的1.5倍（如90秒查询填135），位置在连接→高级→socket timeout(sec)。
Socket Timeout 是唯一能拦住慢 SQL 的客户端参数
Navicat 没有“查询超时”开关，真正起作用的是 Socket Timeout，它控制客户端等待服务端返回结果的最长时间。默认 30 秒，一旦超时，Navicat 会静默终止请求，界面卡死或报“连接已关闭”。这不是数据库挂了，是 Navicat 主动放弃了。
这个值必须设为预期最长查询耗时的 1.5 倍——比如你允许报表类 SQL 最多跑 90 秒，就填 135；若只是日常调试，填 60 足够。别留空，也别设成 0（表示无限等待）。
- 位置：右键连接 → Edit Connection → Advanced →
Socket Timeout(sec) - 注意：该设置只对当前连接生效，批量修改需导出/导入连接配置文件
- MySQL、PostgreSQL、SQL Server 都认这个参数，但 PostgreSQL 下可能被
statement_timeout覆盖（见下一条）
PostgreSQL 用户必须同步设 statement_timeout
PostgreSQL 驱动层（libpq）会优先响应服务端的 statement_timeout，Navicat 的 Socket Timeout 可能根本没机会触发。也就是说，即使你把 Socket Timeout 设成 300 秒，只要服务端 statement_timeout = '30s'，30 秒一到，连接就被 PG 强制中断。
验证当前值：SHOW statement_timeout;
- 全局设（影响所有新连接）：
ALTER DATABASE mydb SET statement_timeout = '120s'; - 单用户设（更安全）：
ALTER ROLE app_user SET statement_timeout = '90s'; - 临时会话设（仅本次连接）：
SET statement_timeout = '60s';
别让 Navicat 自己执行两次 SQL
开着 Explain 面板、Profile 面板，或者右键结果窗口点“刷新执行计划”，Navicat 会悄悄把同一条 SQL 执行两遍：一遍取数据，一遍取执行计划。耗时直接翻倍，还容易触发超时。
- 查慢 SQL 时，先关掉
Explain plan和Profile面板 - 右键结果窗口 → 关闭
Auto-refresh result set - 避免在同一个查询窗口里反复点击“运行”——旧结果未清空时再点，可能触发隐式重执行
超时不是万能解，索引缺失才是根因
把 Socket Timeout 设成 300 秒，只是让你“看得见慢”，不是“解决慢”。真正拖垮生产库的，是没走索引的全表扫描。Navicat 里右键 SQL → “解释”，盯住三列：
-
type = ALL：全表扫描，立刻加索引 -
key = NULL：有索引但没用上，检查 WHERE 字段类型是否匹配、有没有函数包裹（如UPPER(name)） -
rows远大于实际返回行数：索引选择性差或统计信息过期，运行ANALYZE TABLE table_name;
超时设置只是兜底手段，索引和执行计划才是你每天该盯住的地方。否则调再大的超时，也只是把“炸库”从 30 秒延后到 300 秒而已。
