Navicat同步中断后报ERROR 1062是因无断点续传逻辑，重启时重复插入已存在记录；应手动定位最后成功ID、删脏数据、加WHERE条件限定范围再同步。
Navicat 同步中断后报 ERROR 1062 或 Duplicate entry 怎么办
这不是数据冲突，是 navicat 同步任务重启时没跳过已成功写入的记录，硬要重插主键/唯一键重复的行。它默认不带断点续传逻辑，所谓“续传”只是从头再跑一遍，失败就卡住。
实操建议：
- 手动确认中断前最后成功同步的
id或updated_at值（查目标库最新记录） - 改用
INSERT IGNORE或ON DUPLICATE KEY UPDATE模式——但 Navicat 图形界面里没有这个开关，得导出 SQL 脚本后手改 - 更稳的做法：停掉同步任务 → 在目标库删掉最后几条可能重复的脏数据 → 用
WHERE id > ?手动限定源表拉取范围 → 再执行
Navicat 数据同步依赖外键约束导致中途失败
外键会强制校验关联表存在性，而同步往往是分表进行、顺序不确定的。比如先同步 order 表，但 user_id 对应的 user 记录还没写进去，立刻报 ERROR 1452。
实操建议：
- 同步前在目标库临时禁用外键检查：
SET FOREIGN_KEY_CHECKS = 0;，同步完再开：SET FOREIGN_KEY_CHECKS = 1; - 别依赖 Navicat 自动识别依赖顺序——它只看表级外键声明，不分析实际数据流向；务必按真实依赖链手动排同步顺序（如先
user，再order，最后order_item） - 如果目标库不能关外键（比如生产环境），就提前在源库导出时加
--skip-foreign-key-checks（mysqldump 场景），或用 Navicat 导出为无约束 SQL
Navicat 同步任务中 ON UPDATE CURRENT_TIMESTAMP 字段被意外覆盖
Navicat 默认把整行当“新数据”全量更新，哪怕你只想同步几个字段，它生成的语句也会把 updated_at 这类自动时间戳字段设成当前时间，破坏原始业务含义。
实操建议：
- 在 Navicat 同步设置里勾选
Use primary key for update（有主键才生效），并确保「仅更新变更字段」选项打开（不同版本叫法略有差异，找含update only changed columns的勾选项） - 如果仍不行，导出同步脚本 → 把生成的
UPDATE ... SET updated_at = NOW(), ...改成SET col1 = ?, col2 = ?，显式排除时间戳字段 - 长期来看，这类字段不该参与同步逻辑，应在目标库用触发器或应用层保证，而不是靠同步工具搬运
为什么 Navicat 不推荐用于大表断点续传场景
它底层不是基于 binlog 或 CDC，而是查源表全量快照 + 对比目标表，内存占用高、锁表久、没法按 GTID 或 position 断点。10 万行以上就容易超时、OOM 或主从延迟恶化。
实操建议：
- 小表（pt-table-sync 或
gh-ost+ 自定义 offset 控制 - 真要用 Navicat 大表同步，必须分批次：按
id BETWEEN ? AND ?切块，每块单独建任务，失败只重跑那块 - 记得关掉 Navicat 的「实时预览」和「进度刷新」，这两项在大数据量下反而拖慢执行、增加连接中断概率
断点续传真正的难点不在“怎么接着跑”，而在“怎么定义‘接着’的位置”——Navicat 不暴露同步位点，也不记录 last_pk，所有所谓续传都是人工估算，误差一多就漏数据或重复写。这点很容易被忽略。
