这是唯一键冲突错误，表明同步时目标表已存在相同主键或唯一索引值的记录，Navicat 默认严格插入导致报错中断。
同步报 Duplicate entry for key 'xxx' 是什么情况
这是最典型的唯一键冲突提示，duplicate entry '123' for key 'primary' 或 for key 'uk_email' 都说明：源和目标表中，同一张表的同一行（由主键或唯一索引确定）在两边都有记录，但 navicat 尝试执行 insert 时发现目标已有该键值。
它不是 Navicat bug，也不是网络问题，而是数据状态不一致的明确信号——比如你本地改了用户邮箱，同事刚在测试库也改了同个 ID 的手机号，两边都存了，同步时就撞上了。
Navicat 默认行为是「严格插入」：遇到已存在主键/唯一键，直接报错中断，不会自动跳过或覆盖。
Insert records 和 Update records 勾选逻辑怎么配
这两个选项控制 Navicat 对「同键不同值」的处理方式，不是互斥开关，而是协同生效：
-
Insert records：只对目标库**没有**该主键/唯一键的行执行INSERT -
Update records：只对目标库**已有**该主键/唯一键、但其他字段值不同的行执行UPDATE - 两者都不勾选 → 什么都不做；只勾
Insert→ 不更新已有数据；只勾Update→ 不新增任何行
关键点：Navicat 判断「是否存在」依赖你设置的 Key Mapping。如果映射的不是主键或唯一索引（比如只映射了普通字段 name），就会误判多行“都不存在”，反复 INSERT 导致冲突。
实操建议：务必在 Step 2 的 Key Mapping 中，确认选中的是主键列或业务上真正唯一的索引列（如 order_no、email），否则再怎么调策略都没用。
Skip duplicate key errors 要不要开
这个选项在同步向导 → 「选项」→「错误处理」页里，作用是让 Navicat 遇到 Duplicate entry 时自动跳过该行，不中断后续同步。但它有明确前提：
- 仅 Navicat 15+ 支持；旧版本没这开关，必须手动改 SQL 或清空目标表
- 它等效于在生成的 SQL 中加
INSERT IGNORE，不会触发ON DELETE或外键级联 - 启用后，冲突行被静默跳过，日志里只记 warning，不报 error —— 如果你依赖报错来发现数据异常，反而会漏掉问题
更稳的做法是：先关掉这个选项，点 Compare & Preview，在预览界面直接看到哪些行冲突、值差在哪，再人工决定是取消勾选、交换源目标，还是导出 SQL 手动加 REPLACE INTO（注意 REPLACE 会删再插，可能丢失自增 ID 或触发删除逻辑）。
为什么勾了 Update 还报 Duplicate 错误
常见于两种场景：
- 目标表有自增主键，但源表导出时没带该 ID 值（比如用 Navicat 数据传输导出 SQL 时没勾「导出 AUTO_INCREMENT 值」），导致同步时 Navicat 尝试
INSERT新行，而非UPDATE已有行 - 表结构里定义了
UNIQUE KEY (a, b)，但 Key Mapping 只设了单列a，Navicat 就无法识别复合唯一约束，把两行(1,'x')和(1,'y')都当成「新行」去插
验证方法：在目标库手动执行 SHOW CREATE TABLE table_name，对照 Navicat 映射的 Key 列，确认是否完全覆盖所有唯一约束字段。不一致就立刻改映射，别硬调策略。
复杂点在于：冲突本身不可怕，可怕的是把它当配置问题去调，而忽略背后的数据一致性漏洞。比如连续三次在 users 表上遇到冲突，大概率不是 Navicat 设置不对，而是团队没约定好谁才是权威源，或者没禁用双向同步。
