Navicat数据同步不支持自动断点续传，因其底层依赖全表SELECT+主键比对，无binlog/WAL监听、无事务位点与checkpoint机制；唯一可行续传路径是启动前启用自定义记录集切片或编写带条件的自定义查询。
Navicat 数据同步本身不支持自动断点续传——所谓“续传”必须靠人工干预，且前提是任务启动前就做了关键配置；没提前启用自定义记录集，中断后重跑大概率重复写入或清空已有数据。
为什么“中断后自动继续”根本不存在
Navicat 的数据同步(Data Sync)底层仍是全表 SELECT + 主键比对，不监听 binlog 或 WAL，无法记录位点。它没有事务位点、没有 checkpoint 表、不保存已处理行的 ID 或时间戳。
- 界面里所有“自动重连”“保持连接间隔”只管 TCP 层是否通，跟数据进度无关
- 任务中断后，Navicat 停在失败那一步，不会自动跳过已成功部分，也不会记住最后插入的
id - 日志窗口默认只显示最近几百行，最后一条成功 SQL 很可能被滚走；不右键导出完整日志，90% 的人会误判断点位置
真正能用的续传路径只有两条
必须在点击“开始同步”之前就完成配置，事后补救基本无效。
- 启用
高级模式→ 勾选自定义记录集→ 用记录集生成器按主键（如id）切片（例如每 5 万条一组），生成dataset_001、dataset_002等独立任务；中断后手动勾选从失败序号起的 dataset，前面成功的不会重跑 - 在
表映射→编辑→自定义查询中写带条件的 SQL，例如SELECT * FROM orders WHERE id > 123456；字段必须有索引，且目标表需已存在对应数据，否则首段会漏
常见续传翻车点：你以为在续，其实已在重头跑
这些操作看似合理，实际都会导致全量覆盖或重复插入：
- 没开
自定义记录集，却指望“自动重连”后点“继续”就能接着上次跑 - 在
错误处理页勾了Skip duplicate key errors，但该选项仅对 MySQL 15+ 有效，且只跳过 INSERT 冲突，对 UPDATE/DELETE 失效；旧版本或 SQL Server 完全不认这个开关 - 用时间字段（如
updated_at）做 WHERE 条件，但源库该字段是ON UPDATE CURRENT_TIMESTAMP，业务一更新就变，导致同一行被反复同步 - 跨库迁移时，把源库的
SHOW MASTER STATUS输出当续传起点，而目标库根本没有对应 binlog 位点，纯属幻觉
最易被忽略的是：Navicat 同步失败后，断点不在报错行，而在上一条成功执行的 SQL —— 这个位置藏在导出的日志文件末尾，不是界面上滚动可见的那几行。
