Navicat导入任务卡住报“连接已关闭”是Socket Timeout未调整所致：其默认30秒仅控制SQL执行等待，需在连接高级设置中手动设为预期最长耗时的1.5倍（如120秒脚本填180），单位为秒且不可带单位字符串。
Navicat 导入任务卡住报“连接已关闭”是 Socket Timeout 没调
导入大 sql 文件或大批量数据时，navicat 界面突然卡死、无报错、后续操作全部失效——这不是网络断了，而是 socket timeout 默认 30 秒触发后静默终止连接。它和“连接超时（connection timeout）”完全无关，后者只管点击“连接”按钮到认证完成那几十秒。
解决方法很简单：右键目标连接 → Edit Connection → 切换到 Advanced 页签 → 找到 Socket Timeout(sec) 输入框，填入预期最长单次导入耗时的 1.5 倍（例如含百万行 INSERT 的脚本预计跑 120 秒，这里填 180）。
- 该值单位是秒，不能带单位字符串（如
180s会失效） - 若导入中途仍断开，说明语句实际执行时间超过该值，需再调高或拆分脚本
- MySQL 用户注意：
max_allowed_packet不足也会表现为“连接重置”，需同步检查服务端配置
Linux 版 Navicat 导入失败常因 KeepaliveInterval 设错
Linux 桌面版 Navicat（如 17.x）没有“Socket Timeout”滑块，Socket Timeout 字段被隐藏，真正能调的是 KeepaliveInterval——但它不是控制导入超时，而是防空闲断连。导入大文件时，Navicat 解析 SQL 或等待服务端返回结果期间可能长时间无网络活动，触发服务端 wait_timeout 回收连接。
必须做三件事：
- 先连上库执行
SELECT @@wait_timeout;，确认服务端真实值（云数据库常见为300或600） - 在连接“高级”页中设置
KeepaliveInterval为该值的 一半以内（如@@wait_timeout = 300，则填120） - 务必勾选
Keepalive，并取消勾选Only send ping when there is a query（否则空闲时不发心跳）
PostgreSQL / SQL Server 导入超时要查驱动层限制
即使你把 Navicat 的 Socket Timeout 调到 600 秒，PostgreSQL 用户仍可能遇到“query cancelled due to statement timeout”错误——这是服务端 statement_timeout 在起作用，优先级高于客户端设置。
执行以下命令确认当前值：
SHOW statement_timeout;
临时调整（当前会话有效）：
SET statement_timeout = '600s';
永久生效（需管理员权限）：
ALTER DATABASE mydb SET statement_timeout = '600s';
- SQL Server 用户注意：ODBC 驱动自带
Connect Timeout=30隐式参数，Navicat 不暴露该字段；建议换用 JDBC 连接模式，或升级 ODBC 驱动至支持自定义超时的版本 - 所有驱动都可能覆盖 Navicat 设置，不能只信界面参数
导入中断后不会续传，必须手动跳过已执行部分
Navicat 的数据或结构同步任务一旦中断，不会记录进度，重试就是从头再来。这和 MySQL 官方 mysql 命令行工具的 --force 或 --continue 完全不同。
规避办法只有两个：
- 导入前用文本编辑器把大 SQL 拆成多个小文件（按表或按十万行切分），逐个执行
- 对关键表启用“忽略重复主键/唯一键错误”选项，避免因少量冲突导致整批失败
- 不要依赖 Navicat 自动重连——它重连后不会接着上次断点走
最麻烦的不是设超时，而是没意识到 Navicat 根本不记进度。这点比任何参数都容易被忽略。
