Navicat还原提示“Duplicate entry”说明目标库已存在同主键或唯一键记录，而默认严格INSERT不跳过不覆盖；需导出SQL手动替换为INSERT IGNORE或REPLACE INTO，或启用16+版Skip duplicate key errors选项。
navicat 还原时提示 duplicate entry，说明目标库已存在同主键或唯一键的记录，而 navicat 默认执行严格 insert，不跳过、不覆盖、不询问——你得主动干预，否则流程必然中断。
还原前先确认冲突在哪一行
报错里带的具体值（比如 Duplicate entry '105' for key 'PRIMARY'）就是线索。别急着改设置，先定位问题根源：
- 在目标库执行
SELECT * FROM table_name WHERE id = 105;，确认该主键是否真存在 - 再查源数据（或导出的 SQL 文件），看是否也含
INSERT INTO ... VALUES (105, ...) - 如果表有唯一索引（如
email或order_no），用SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1;检查源数据本身是否就含重复
很多情况下，错误不是同步逻辑问题，而是源文件或目标库数据状态异常——比如 Excel 导入时重复拖拽了同一行，或多人本地各自插入了相同业务编码。
用 INSERT IGNORE 或 REPLACE INTO 替换原始 INSERT
Navicat 图形界面里没有“一键替换”开关，必须导出 SQL 后手动处理。这是最可控、可审计的做法：
- 在还原向导中勾选「导出为 SQL 文件」，保存后用文本编辑器打开
- 全局搜索
INSERT INTO `table_name`，替换成INSERT IGNORE INTO `table_name`（跳过冲突，保留原记录） - 若需以新数据为准（比如时间戳、状态字段必须更新），则替换成
REPLACE INTO `table_name` - 执行前在目标库运行
SET FOREIGN_KEY_CHECKS = 0;，避免外键约束打断批量执行；完事后记得SET FOREIGN_KEY_CHECKS = 1;
注意：REPLACE INTO 本质是 DELETE + INSERT，会重置自增 ID、触发 ON DELETE 行为、清空 ON UPDATE CURRENT_TIMESTAMP 字段——这些副作用在日志里往往只显示为 warning，容易被忽略。
新版 Navicat 的 Skip duplicate key errors 不等于万能开关
Navicat 15+ 在「选项 → 错误处理」页里确实提供了 Skip duplicate key errors 勾选项，但它只是让工具层静默跳过 ERROR 1062，等效于加 IGNORE，并不改变底层语义：
- 它只对
INSERT生效，UPDATE和DELETE仍按原逻辑走 - 不会修复外键或触发器行为，也不会防止
REPLACE引发的级联删除 - Mac 用户连 MySQL 8.0+ 时，若认证插件是
caching_sha2_password，这个选项可能失效（需手动勾选Use MySQL Native Password） - 一旦启用，所有冲突都变成 warning，日志里不报 error——如果你靠报错来发现脏数据，反而会漏掉真正该人工介入的 case
所以它适合临时救急，不适合长期依赖。真正频繁出现 Duplicate entry，说明同步策略本身有问题：比如没明确权威源、允许多向同步、或没做导入前去重校验。
导入 Excel/CSV 时的特殊陷阱
这类场景下报错（如 Duplicate entry '配置' for key 'cn'），往往和索引定义与数据质量强相关：
-
cn字段设了UNIQUE，但 Excel 里“配置”出现了多次——不是 Navicat 问题，是源数据未清洗 - Navicat 导入向导默认把第一行当列名，但如果 Excel 有空行或合并单元格，可能错读数据，导致重复插入同一行
- 字段类型不匹配也会诱发隐式冲突：比如目标
id是BIGINT，Excel 里写成文本型 “1000001”，Navicat 可能转成 0 或截断，最终撞上Duplicate entry '0' for key 'PRIMARY'
建议先导出为 SQL 再检查，比直接导入更易定位；若必须直连 Excel，务必提前在 Navicat 导入设置中指定字段类型，并勾选「跳过空行」和「忽略标题行」。
