协作场景下不能共用默认socket timeout，因为不同角色（如dba、开发者、etl任务）执行的操作类型、时长需求及所连数据库实例（dev/staging/prod）差异显著，统一设值会导致合法长操作失败或慢查询问题被掩盖，必须按角色、用途和实例层级差异化配置连接参数。
协作项目里连接超时不是“统一设个值就完事”，而是要区分角色、操作类型和数据库实例层级来配——否则有人改表卡死，有人查数据断连，协作反而更乱。
为什么协作场景下不能共用默认 Socket Timeout
Navicat 的 Socket Timeout(sec) 是每个连接独立配置的，但它控制的是“客户端等待服务器返回结果的最大时长”。在协作中：
- DBA 执行
ALTER TABLE可能需要 10 分钟，设 30 秒必断 - 前端开发者跑
SELECT * FROM logs LIMIT 100本该秒出，设 600 秒反而掩盖慢查询问题 - 不同成员连接的是同一套库的不同实例（如 dev / staging / prod），而云 RDS 的
wait_timeout可能分别是 300 / 600 / 28800 秒
强行统一设高值，会导致异常阻塞不暴露；设低值，又让合法长操作失败。必须按需隔离。
为不同角色/用途创建专用连接并差异化配置
不要让所有人共享一个连接配置。应在 Navicat 中为每类协作行为新建独立连接，并绑定对应超时策略：
- 命名规则建议：用前缀标识用途，例如
prod-dba-maint、staging-dev-query、dev-etl-batch - 对
prod-dba-maint：在 Advanced 页设Socket Timeout(sec)= 1800，勾选Keep connection alive间隔 60，SQL Query 框填SET SESSION wait_timeout = 28800; - 对
staging-dev-query：Socket Timeout(sec)= 60，不启用 Keep-alive，SQL Query 留空——靠服务端默认值兜底，便于快速暴露性能问题 - 对
dev-etl-batch：若走 SSH 隧道，必须同步配 SSH 的ServerAliveInterval 15（在连接的 SSH 页设置），否则心跳发不到隧道终点
PostgreSQL 协作项目要额外配 statement_timeout
MySQL 靠 wait_timeout 控制空闲，但 PostgreSQL 的 statement_timeout 是真正在执行层掐断语句的开关。协作中必须分层设：
- 全局兜底（DBA 执行）：
ALTER DATABASE myapp_staging SET statement_timeout = '300s'; - 开发只读账号（防误操作）：
ALTER ROLE dev_user SET statement_timeout = '10s'; - ETL 专用账号（允许长跑）：
ALTER ROLE etl_job SET statement_timeout = '7200s';
注意：Navicat 连接后不会自动继承 role 级别的 statement_timeout，除非你用该 role 登录——所以协作账号必须严格按角色建，不能全用 postgres 或 root。
容易被忽略的协作断连诱因：事务残留与连接复用
多人共用连接池或频繁切换标签页时，以下情况会让超时设置全部失效：
- 某人执行了
BEGIN但没COMMIT或ROLLBACK，连接卡在事务中，wait_timeout不生效，但连接资源被占，后续操作排队或超时 - Navicat 的“查询”标签页默认复用连接，A 在跑大查询，B 新开标签页执行
SHOW PROCESSLIST，可能被 A 的锁阻塞，再叠加 Socket Timeout 就报错 - 团队共用一份导出的 .ncx 连接文件，但本地 Navicat 版本不一致（如 v15 和 v16），某些高级参数（如 keep-alive 行为）解析不同
真正稳的协作，不是调高所有 timeout，而是明确谁在什么连接上做什么事，并接受“该超时的地方必须超时”——它本就是发现瓶颈的第一信号。
