Socket Timeout是Navicat中唯一可控的客户端执行超时参数，控制发完SQL后等待服务端响应的最长时间，默认30秒；需在连接高级设置中设为预期查询耗时的1.5倍（如80秒填120），单位为纯数字秒，修改后须重新连接。
Socket Timeout 是唯一可控的客户端执行超时参数
Navicat 16 没有叫“SQL运行超时”的独立开关，真正起作用的是 Socket Timeout(sec) ——它控制客户端等待服务端返回结果的最长时间，默认仅 30 秒。超过该值，Navicat 会静默断开连接，界面卡死或报“连接已关闭”，但不是网络真断了。
这个值和“Connection Timeout”（建连认证超时）完全无关，也和数据库服务端的 wait_timeout 或 statement_timeout 不同：它只管“发完 SQL 后等多久没回包就放弃”。
- 右键目标连接 → Edit Connection → 切换到 Advanced 页签
- 找到
Socket Timeout(sec)输入框，填入预期最长单次查询耗时的 1.5 倍（例如预计最慢查询跑 80 秒，填120） -
单位是纯数字秒，不能带
s或空格，填120s会失效 - 修改后必须重新连接（双击该连接），旧标签页仍沿用旧设置
MySQL 用户必须同步检查 max_allowed_packet
即使 Socket Timeout 调高了，导入大 SQL 文件或 SELECT 大结果集时仍可能中断，且错误现象高度相似（如“连接重置”“Unexpected end of input”）。这时大概率是服务端 max_allowed_packet 不足，导致数据传输中途被截断。
- 连上库后执行：
SHOW VARIABLES LIKE 'max_allowed_packet'; - 若返回值 ≤ 4194304（即 4MB），对百万行 INSERT 或宽表导出明显不够
- 临时调高（当前会话）：
SET SESSION max_allowed_packet = 1073741824;（1GB） - 永久生效需改 MySQL 配置文件
my.cnf并重启服务，或联系 DBA
PostgreSQL / SQL Server 用户要绕过驱动层硬限制
Navicat 的 Socket Timeout 在 PostgreSQL 和 SQL Server 场景下常被底层驱动覆盖，单独调整基本无效。
- PostgreSQL：服务端
statement_timeout优先级更高，执行SHOW statement_timeout;查当前值；临时设为 600 秒：SET statement_timeout = '600s'; - SQL Server：ODBC 驱动隐含
Connect Timeout=30，Navicat 不暴露该参数；建议换用 JDBC 连接模式，或升级 ODBC 驱动至支持自定义 socket timeout 的版本 - 两者都需确认服务端真实
wait_timeout（PostgreSQL 是tcp_keepalives_idle等），再反推客户端KeepaliveInterval设置
别把“停止按钮”当超时保险
点击 Navicat 查询窗口左上角的 停止 按钮，只是发 KILL QUERY 请求，并不等于强制终止。它是否生效取决于服务端当前状态：
- 若
SHOW PROCESSLIST中 State 是Locked、Waiting for table metadata lock，kill 会被挂起直到锁释放 - 若正在做 InnoDB 回滚（比如大事务被中断），线程显示
Rolling back，kill 已触发但不可逆 - 普通账号无
SUPER权限时，KILL类命令直接报Access denied - 更可靠的方式是打开 工具 → 服务器监控 → 进程，右键选“终止查询”，它比手动写 SQL 更稳定
真正影响超时行为的是 Socket Timeout 和服务端配置的协同，而不是靠点停止按钮来补救——后者只是应急手段，不是超时机制本身。
