Navicat「仅插入」需目标表有主键或唯一索引，否则无法识别重复而报错或跳过；真正增量须手动在「表映射」设过滤条件（如created_at > '2026-05-28'），并关闭删除和冲突更新选项。
选「仅插入」模式但目标表必须有主键或唯一索引
navicat 的「仅插入」（insert only）不是无条件追加，它依赖目标表存在明确的主键或唯一索引，才能判断“是否已存在”。如果目标表没设主键，navicat 无法识别重复，会直接报 duplicate entry 错误或静默跳过部分行。
常见错误现象：同步后目标行数远少于预期，日志里却显示“completed”，实际是因缺失主键导致 Navicat 放弃比对、批量跳过。
- 确认目标表执行
SHOW CREATE TABLE table_name，输出中含PRIMARY KEY或UNIQUE KEY - 若用复合唯一索引（如
(user_id, action_type)），需在 Navicat「表映射 → 键映射」中手动指定这些字段为匹配依据 - MySQL 中
INSERT IGNORE是底层机制，但 Navicat 不暴露该语句控制权——它只通过键定义决定是否触发忽略逻辑
过滤条件必须写在「表映射」页签的「过滤条件」框里
很多人以为勾了「仅插入」就自动增量，其实不然。Navicat 默认仍全表扫描源数据；不加 WHERE，它会把源库所有行都尝试 INSERT，靠主键冲突来“跳过”，效率低且易撞约束。
真正控制“只插新”的，是你手动写的过滤条件，比如 id > 10000 或 created_at > '2026-05-28 00:00:00'。这个输入框只在「表映射」页签里，不在「高级」或「选项」里。
- 时间字段务必确认时区一致：源库是 UTC，Navicat 客户端设为 CST？那
created_at > NOW() - INTERVAL 1 DAY就会漏掉 8 小时数据 - 别用
BETWEEN，边界秒级数据容易丢失；用>+ 昨日零点更稳妥 - 如果源表有归档或 ID 重用，单靠
id > N不可靠，建议叠加AND created_at > '2026-05-28'双保险
关闭「删除目标中不存在的记录」并禁用冲突更新
即使选了「仅插入」，如果误勾了「删除目标中不存在的记录」，Navicat 会在同步前先执行 DELETE —— 这和“只插新”完全相悖，会导致历史数据被清空。
同时，「冲突处理」必须设为「跳过」，不能选「更新现有记录」或「停止」。后者一遇到主键冲突就中断任务，前者则违背“不更新”的前提。
- 入口在「同步设置 → 高级 → 冲突处理」，选
skip（不是update或stop） - 「删除目标中不存在的记录」勾选项默认常为启用状态，每次新建任务都要手动取消
- PostgreSQL/SQL Server 用户注意：它们不支持
INSERT IGNORE，Navicat 在「仅插入」下仍走SELECT + INSERT流程，高并发时可能因竞态多插一次——得靠上游业务层控频或加应用锁
外键约束报错时不能只靠禁用检查
当出现 Cannot add or update a child row: a foreign key constraint fails，说明子表（如 orders）正试图插入一条引用父表（如 users）不存在的记录。此时若简单勾选 Disable foreign key checks，虽能过同步，但目标库数据逻辑已损坏。
更安全的做法是理清依赖顺序，或确保父表同步早于子表。
- 在 Navicat 同步向导中点击「高级」→ 手动拖拽表顺序，把
users拖到orders上方 - 若无法改顺序（如跨库不同权限），可在「表映射」中对子表单独加过滤条件，例如
user_id IN (SELECT id FROM users)（仅限同库） -
Disable foreign key checks仅限 MySQL/MariaDB，且同步完成后约束自动恢复——但它不管数据本身是否自洽，只是绕过校验
实际执行时最容易被忽略的是：「仅插入」不等于「安全增量」。它只保证不覆盖旧数据，但不保证只同步新增——漏写过滤条件、主键不一致、外键依赖断裂，都会让结果偏离预期。每次同步前，务必打开「Compare & Preview」看预估 Insert 行数是否合理。
