socket timeout位于连接编辑页「高级」选项卡中，windows与linux版路径一致但linux界面更紧凑需滚动查找；单位为秒，留空或填0则用驱动默认30秒；它控制sql执行阶段读取超时，非连接建立超时。
Windows 和 Linux 版 Navicat 的 Socket Timeout 设置位置、行为和生效逻辑完全一致，但 Linux 版隐藏了部分 UI 元素，容易误以为“没这个选项”——实际只是入口路径不同。
Socket Timeout 参数在哪设？
它不在“连接超时”（Connection Timeout）字段里，也不叫“查询超时”，而是明确标为 Socket Timeout(sec)，位于连接编辑页的「高级」选项卡中：
- Windows：右键连接 → Edit Connection → Advanced → 找到
Socket Timeout(sec)输入框 - Linux：右键连接 → Edit Connection → Advanced → 同样有
Socket Timeout(sec)，但界面更紧凑，可能需要滚动或展开「更多设置」区域（无滑块，纯数字输入） - 注意：该值单位是秒，不是毫秒；留空或填 0 表示使用驱动默认值（通常是 30 秒），不是禁用超时
为什么设了还是被中断？常见三类干扰
即使两端都填了相同的 Socket Timeout 值，查询仍可能提前终止，原因往往不在 Navicat 本身：
- 服务端强制限速：MySQL 的
max_execution_time（如SET SESSION max_execution_time = 120000）会强于 Navicat 设置；PostgreSQL 的statement_timeout同理，需查SHOW statement_timeout; - 底层驱动覆盖：SQL Server 的 ODBC 连接字符串隐含
Connect Timeout=30，Linux 下若用旧版 unixODBC，Socket Timeout可能完全不生效 - 大结果集触发传输中断：MySQL 的
max_allowed_packet不足时，Navicat 在接收第 N 行时静默断连，报错却是“connection was closed”，容易误判为超时
跨平台统一配置的关键验证点
光填数字没用，必须确认三件事是否在 Windows 和 Linux 上表现一致：
- 执行同一条慢查询（例如
SELECT SLEEP(45)），观察是否都在第 45 秒左右中断 —— 若 Windows 精准 45 秒、Linux 却在 30 秒断，说明 Linux 下某层 socket 超时未被覆盖 - 检查 Navicat 日志：
Help → View Log File，搜索socket timeout或read timed out，Linux 版日志中常出现java.net.SocketTimeoutException，说明是 JVM 层拦截，非 Navicat 应用层 - 确认数据库驱动版本：Linux 版 Navicat 默认捆绑较旧 JDBC/ODBC 驱动，
Socket Timeout可能被驱动忽略；可手动替换lib/目录下的 jar 或 so 文件（需匹配 Navicat 架构）
最易被忽略的是：Linux 版 Navicat 不读取系统 /etc/environment 或 shell 的 ulimit 设置，如果查询涉及大量本地内存排序（如 ORDER BY + LIMIT 大偏移），Linux 端可能因 OOM 被 kill，现象和超时一模一样——此时调任何 Socket Timeout 都无效。
