PostgreSQL查询超时必须由服务端statement_timeout强制控制，Navicat仅能辅助查看或执行设置；其自身超时参数仅管理连接与读取，不干预SQL执行时间。
不能靠Navicat客户端统一配置查询超时策略——它只管连接和读取，不控制SQL执行时间。真正生效的查询超时必须由数据库服务端强制干预，Navicat最多能辅助查看或触发设置。
PostgreSQL 的 statement_timeout 必须在服务端设
Navicat 本身没有“全局查询超时”开关。你在 Navicat 里执行的任何 SQL，是否被中断，完全取决于 PostgreSQL 是否启用了 statement_timeout。这个变量有三个作用层级，优先级从高到低：
- 会话级（当前连接）：
SET statement_timeout = '30s';—— 断开重连即失效 - 用户级（对指定角色永久生效）：
ALTER ROLE myuser SET statement_timeout = '60s'; - 数据库级（影响所有连入该库的用户）：
ALTER DATABASE mydb SET statement_timeout = '45s';
团队协作中推荐用数据库级或用户级设置，避免每个成员手动 SET。注意：Navicat 的「测试连接」不会触发该变量，必须实际执行查询才会生效。
MySQL 没有等效的 statement_timeout，得用 max_execution_time
MySQL 5.7.8+ 支持 max_execution_time，但它是会话级变量，且默认为 0（不限制）。团队要统一，只能靠初始化脚本或中间件注入：
- 连接建立后自动执行：
SET SESSION max_execution_time = 30000;（单位毫秒） - 在 Navicat 的「高级」→「初始化命令」里填这句，每次连接都会运行
- 但该设置对已存在的连接无效，也不能跨连接继承；若用连接池或长连接，需额外机制保证
注意：max_execution_time 对 SELECT 有效，对 INSERT/UPDATE/DELETE 无效，且不兼容所有存储引擎（如 MyISAM 不支持）。
Navicat 自身的超时参数只管“连不上”和“读不到”，不管“查太慢”
很多人混淆了三类超时，它们互不替代：
-
连接超时（Connection Timeout）：Navicat 尝试 TCP 握手的最大等待时间，设在「高级」选项卡，默认 30 秒 -
读取超时（Read Timeout）：Navicat 等待服务器返回第一条结果的时间，也设在「高级」，默认 60 秒 -
查询执行超时（Statement Timeout）：服务器主动 kill 掉慢 SQL 的时间，Navicat 完全不参与控制
如果你在 Navicat 里执行一个 SELECT SLEEP(120)，前两秒没反应是 读取超时 触发断连；但如果服务器开了 statement_timeout = '60s'，60 秒一到，PostgreSQL 就直接终止查询并返回错误，Navicat 只是收到这个结果而已。
团队落地时最容易忽略的两个点
一是权限：设置 ALTER DATABASE 或 ALTER ROLE 需要超级用户或相应数据库的 CREATEDB/CREATEROLE 权限，普通开发账号通常没有；二是生效范围：ALTER DATABASE ... SET 不会影响已存在的连接，新连接才生效，所以改完要通知团队重启 Navicat 连接或刷新会话。
