navicat跨高延迟网络同步必须手动优化：设每批2000–5000条、启用45秒主动ping保活、关闭外键检查与事务，并通过where条件人工分片切片，否则因超时断连导致同步失败。
Navicat 在跨网络高延迟环境下做数据同步，不能靠默认设置硬扛——必须手动拆批次、控连接、压查询粒度，否则大概率卡死或中断。
为什么默认同步在高延迟下会失败
Navicat 默认按表全量拉取再比对，中间依赖长连接维持状态。当网络 RTT 超过 300ms（比如跨国专线、云厂商跨可用区链路），MySQL 的 wait_timeout 和中间设备（如 AWS NLB、阿里云 SLB）的空闲超时（常为 60–120 秒）会先于 Navicat 发起断连，导致报错 Lost connection to MySQL server during query 或 Commands out of sync。这不是 Navicat 崩溃，而是 TCP 连接被上游掐断。
常见误操作包括：调大 Navicat 内存参数（-Xmx）、改系统 TCP keepalive（无效，Navicat 不走标准 socket 保活）、或指望「保持连接活跃」勾选项兜底（它只在有查询时发 ping，空闲阶段照样断）。
必须改的三项关键设置
以下操作需在「数据同步」向导 Step 1 的「Options」页和右键连接编辑中完成：
- 在「高级」→「每批记录数」中设为
2000～5000：设太高（如 50000）会让单次 SELECT 耗时过长，触发超时；设太低（如 500）则事务过多、网络往返放大，总耗时反而上升 - 对源库和目标库连接分别右键 →「编辑连接」→「高级」→ 勾选「保持连接活跃」，并设「每隔(秒)发送一个ping包」为
45，同时取消勾选「仅当有查询时发送ping」：这是唯一能让 Navicat 主动维持 TCP 存活的方式 - 在「Options」页关闭「使用外键检查」和「使用事务」：高延迟下事务锁持有时间不可控，极易死锁或超时；外键检查会额外增加元数据查询轮次，加剧连接压力
WHERE 条件必须填在表映射页 Options 中
想分批同步，不是靠“自动分片”，而是靠人工切片 + 多次运行。例如同步订单表，按时间分 7 批：
进入 Step 2 → 点该表右侧的 Options → 勾选 Use WHERE condition → 输入：created_at BETWEEN '2026-09-01 00:00:00' AND '2026-09-01 23:59:59'
注意：
• WHERE 条件不填在这里，填在「高级」页的任何位置都无效
• 字段名必须是源表真实列名，且该列要有索引，否则扫描全表会加重延迟影响
• 若用 id > ? AND id 分片，务必确认 id 是连续递增的，否则漏数据
同步中途断了怎么办？别重启 Navicat
看到进度条卡住、CPU 归零、日志停在某张表，大概率是连接已断。此时：
- 右键目标连接 →「断开连接」→ 再右键 →「连接」：重连后 Navicat 会恢复上下文，继续从断点后一张表开始（前提是没勾选「使用事务」）
- 如果仍报
Commands out of sync，不要点「重试」：右键该连接 →「复制连接」→ 新建一个同配置连接 → 把原同步任务里的 Target 换成新连接 → 继续执行 - 避免用「Compare&Deploy」跳过预览：高延迟下预览本身也可能超时失败；宁可多花两分钟看预览结果，也别让执行阶段盲目跑全量
真正稳定的跨高延迟同步，从来不是靠一次跑完，而是靠可控切片 + 快速重试 + 连接加固。那些看似“全自动”的方案，往往在第一次超时后就陷入无限重试循环，反而更难定位问题。
