Navicat 增量同步必须手动配置过滤条件，如 id > 10000 或 created_at > '2024-06-01'，否则默认全量同步；需根据业务选“仅插入”或“插入和更新”，并每次同步后手动更新过滤值。
Navicat 增量同步必须靠「时间戳字段 + 自定义过滤」实现
navicat 本身没有“仅同步新增数据”的开关，它不自动识别哪条是增量。真正起作用的是你在「同步设置 → 表映射 → 过滤条件」里手动加的 where 条件，比如 created_at > '2024-06-01' 或 id > 10000。没这一步，点多少次「同步」都是全量比对，白耗时间还可能覆盖旧数据。
常见错误现象：同步后目标库多了重复记录、明明只改了10条，却同步了上万行，基本都是漏写了过滤或用了不可靠的判断字段（比如用 updated_at 但源表有历史数据更新过）。
- 优先选自增
id字段（确保单调递增、无删除重用） - 若只能用时间字段，确认源库时区和 Navicat 客户端时区一致，否则
now()或字符串时间会错位 - 过滤条件必须写在「目标表映射」页签里的「过滤条件」输入框，不是在「高级」或「选项」里
「同步类型」选「插入和更新」还是「仅插入」？看目标主键是否已存在
这个选择直接决定 Navicat 怎么处理已有记录：如果目标表已经有某条 id=123 的数据，而你选了「仅插入」，Navicat 会跳过它；选「插入和更新」，则会拿源数据覆盖目标对应行。
使用场景很实际：做日志类表（如用户行为流水），目标库本就不该有重复 id，选「仅插入」更安全；如果是配置表或状态表，需要下游始终和上游一致，就得选「插入和更新」。
-
仅插入要求目标表主键/唯一键在源端也严格唯一，否则报Duplicate entry错误 -
插入和更新依赖目标表有主键或唯一索引，否则 Navicat 无法定位哪行该更新，会退化成全量覆盖 - 别碰「删除目标中不存在的记录」——除非你明确要清空历史，否则一勾就丢数据
每次同步前必须手动更新过滤条件里的值，没有自动记忆
Navicat 不会记住上次用的 id > 10000，下次同步还得你重新填 id > 10500。这是最常被忽略的坑：人以为点一次就“持续增量”，结果第二次还是从 10000 开始，重复同步中间那 500 行。
实操建议就是老老实实记个数：同步完立刻查源表最大 id，复制进下一次的过滤框。可以用这条 SQL 快速获取：
SELECT MAX(id) FROM your_table;
- 如果用时间字段，建议格式统一为
'2024-06-15 00:00:00'（带秒，避免跨分钟漏数据） - 别用
NOW()或函数表达式——Navicat 过滤框不支持运行时函数，只认静态值 - 想省事？得自己写脚本调用 Navicat CLI（
navicat.exe /sync）传参，GUI 本身做不到自动化
同步失败后不能直接重试，得先检查目标表是否已被部分写入
Navicat 同步是分批执行的，中途断掉（比如网络闪断、目标库锁表），可能导致部分记录已插入，但后续没走完。这时直接点「重试」，重复的 id 会触发主键冲突，报错 ERROR 1062: Duplicate entry 'xxx' for key 'PRIMARY'。
正确做法是先确认失败点：看 Navicat 日志底部最后成功同步的 id 或时间，然后人工删掉目标表里大于这个值的所有新数据（或者用 TRUNCATE 清空再重来——前提是目标表没其他业务在读）。
- 别信「跳过错误继续」——它只会让数据越来越歪，尤其涉及关联更新时
- 生产环境务必在同步前对目标表做
SELECT COUNT(*)快照，同步失败后对比，能快速发现多写或少写 - Navicat 的「日志」窗口默认只显示最近 100 行，长同步容易刷掉关键信息，建议勾选「保存日志到文件」并设路径
WHERE 条件永远指向“还没同步过的下一段”。
