navicat数据传输实现增量同步的关键是在「表options」中手动配置where条件（如created_at > '2026-09-01 00:00:00'），而非依赖高级选项或比对逻辑；该条件直接作用于源表select语句，真正限制拉取范围，必须配合“追加数据”模式、有效主键/唯一索引及关闭“删除目标中不存在记录”选项。
数据传输里填WHERE条件才是控制增量的关键
Navicat 的「数据传输」功能默认全表拉取，不加过滤就是全量搬运。所谓“增量”，必须靠手动在源表查询层就筛出新增数据，而不是靠同步后比对跳过——后者效率低、锁表久、还容易误判。
入口不在「高级选项」，而在：「数据传输」向导 → 选中某张表 → 点右侧 Options → 勾选 Use WHERE condition → 输入条件语句。这里填的 SQL 会直接加在源表 SELECT 后面，真正决定哪些行被拉出来。
- 正确示例：
created_at > '2026-09-01 00:00:00'（注意单引号） - 如果用 ID 锚点，确认它单调递增且未归档：
id > 1234567 - 时间字段务必和源库时区一致；Navicat 客户端设为 CST，但源库是 UTC？那
created_at > '2026-09-01'实际查的是 UTC 时间，会漏掉当天前 8 小时数据 - 别用
BETWEEN，边界秒级数据易丢失；用>+ 明确零点更稳
选“追加数据”模式但必须配主键或唯一索引
「数据传输」里的 Append data（追加数据）不是无脑插入，它依赖目标表存在有效的主键或唯一索引，才能识别重复并跳过。没有这个前提，Navicat 会尝试插入所有行，大概率报 Duplicate entry 中断。
- 执行
SHOW CREATE TABLE table_name，确认输出含PRIMARY KEY或UNIQUE KEY - 若用复合唯一索引（如
(order_id, event_type)），需在「键映射」里手动指定这些字段为匹配依据 - MySQL 底层可能走
INSERT IGNORE，但 Navicat 不暴露该控制权——它只认键定义 - PostgreSQL/SQL Server 用户注意：它们不支持
INSERT IGNORE，Navicat 在追加模式下仍会先SELECT判重，性能开销更大
忽略新字段或禁止覆盖关键字段得手动设
新增字段（如 is_synced）或业务敏感字段（如 updated_at）如果不加干预，会被源表值批量覆盖，导致时间戳错乱或状态丢失。
- 进「字段映射」界面，取消勾选
Match fields by name，避免 Navicat 把source.status错连到target.is_synced - 在该表的
Options里勾选Ignore columns，把不想同步的列加进去（不是“不读”，是“不比对也不写入”） - 如果新字段不允许为 NULL 且没设默认值，同步前得先在目标表执行：
ALTER TABLE table_name MODIFY is_synced TINYINT DEFAULT 0 - 时间字段同步失败常见原因是客户端与源库时区不一致，不是语法问题
定时自动同步要关掉“删除目标中不存在的记录”
很多人配置完「数据传输」+「计划任务」后发现历史数据被清空，罪魁祸首是默认启用的「Delete records not exist in source」。这个选项和“增量”完全相悖，必须每次新建任务都手动取消。
- 该勾选项位置在：「数据传输」→ 「高级」→ 「同步设置」→ 取消勾选
Delete records not exist in source - 同时确认「冲突处理」策略为
Skip，不是Update或Stop；否则一遇到主键重复就中断 - Oracle 和 SQL Server 跨库同步时，类型映射可能出错（如
NUMBER→DECIMAL），建议首次运行前用小范围数据预演 - 超大表（>500 万行）建议开启「分批导入」+「扩展插入语句」，避免单条 INSERT 过长超时
