Navicat批处理任务网络闪断后无法自动续传或回滚，因“自动重连”仅适用于单次查询，不支持批处理中断恢复；必须启用“自定义记录集”分片执行，并协同调优SSH心跳与MySQL超时参数。
Navicat 批处理任务因网络闪断中断，不是重试几次就能恢复的简单问题——它默认不续传、不跳过、不自动回滚，失败后卡在中间状态，已成功同步的部分可能被重复写入或覆盖。
为什么“自动重连”对批处理中断无效
Navicat 的 Reconnect when connection is lost 仅适用于单次查询或手动操作：连接断开后重新建连，然后等待你点“继续”。但批处理（如数据同步、结构迁移、多库导出）一旦中断，任务引擎就停在失败那一步，不会自动从断点 resume，也不会跳过已成功项。
- 现象：日志里出现
Lost connection to MySQL server during query或MySQL server has gone away，任务状态变成“已停止”，右下角同步栏无反应 - 根本原因：批处理是原子化流程，Navicat 不把每个子任务（如每张表同步）当作独立事务来管理；它依赖全程连接存活
- 验证方式：任务中断后立刻手动执行一条
SELECT 1，如果能通，说明连接已恢复——但批处理不会利用这个新连接
必须启用“自定义记录集”实现可控分片
真正能应对闪断的机制叫「自定义记录集」，本质是把一个大任务提前切分成多个可独立执行、带序号、有明确边界的子任务。中断后只需手动勾选从某一片开始，前面成功的完全不动。
- 操作路径：右键同步/传输任务 →
高级模式→ 勾选自定义记录集→ 点记录集生成器 - 关键设置：按主键（如
id）范围切分，每片 5000–50000 行（视单行大小和网络稳定性调整），避免单片过大导致再次闪断 - 生成结果：出现
dataset_001、dataset_002等命名的数据集，每个都可单独勾选运行 - 注意：
全部记录模式下无论是否勾选自动重连，中断 = 重来
SSH 隧道与数据库超时必须协同调优
网络闪断常由中间链路（尤其是 SSH 跳板）主动断连引发，只调 Navicat 或只调 MySQL 都会漏掉关键一环。
- Navicat SSH 设置：勾选
Keep alive，间隔设为30秒（不能大于跳板机ClientAliveInterval） - MySQL 服务端：执行
SET SESSION wait_timeout = 28800000（8 小时），避免空闲连接被回收；若无 SUPER 权限，至少确保interactive_timeout与之匹配 - 跳板机配置（需管理员权限）：
/etc/ssh/sshd_config中确认含ClientAliveInterval 30和ClientAliveCountMax 3，重启sshd - 验证是否生效：中断后看日志里报错前是否有连续多个
PING成功记录
别信“信息日志里没报错就没事”
Navicat 批处理中断后，信息日志常只显示最后一句错误，而真正导致失败的 SQL 可能早几秒就卡住——尤其当使用 INSERT IGNORE 或外键约束校验时，错误被吞掉或延迟抛出。
- 排查动作：中断后立即打开
信息日志页签，手动滚动到底部，搜索ERROR、Warning、Duplicate entry、FOREIGN KEY - 重点检查：失败前 5–10 行是否已有
Query timeout或Lock wait timeout类警告 - 进阶验证：用
SHOW PROCESSLIST查目标库，看是否有长时间Updating或Locked的线程残留
最易被忽略的是：自定义记录集生成后，若源表主键非递增或存在空洞（比如删过大量中间 ID），按范围切片可能漏数据。上线前务必用 SELECT MIN(id), MAX(id) FROM table 和各 dataset 的 WHERE 条件做交叉核对。
