Navicat 导入无一键UPSERT，需在字段映射页手动勾选主键或唯一索引字段为“匹配”才能实现存在则更新、不存在则插入；未设置匹配字段将导致全表更新或报错。
Navicat 导入时选「更新」模式但必须手动勾匹配字段
Navicat 没有“存在则更新、不存在则插入”（即 UPSERT）的一键开关，它靠「更新」操作模式 + 显式匹配字段组合实现。关键不是勾选项，而是让 Navicat 知道“拿哪几个字段去比对是否存在”。
常见错误现象：选了「更新」却报错 Duplicate entry 或全表被覆盖——因为没指定匹配依据，Navicat 默认不生成 WHERE 条件，直接执行 UPDATE 无过滤，等效于全表更新。
- 导入向导第 2 步（字段映射页），找到目标表主键或唯一索引字段（如
id、order_no），点击该列右侧的「匹配」复选框（中文版显示为“匹配”，英文版是 Match） - 必须逐个确认每个匹配字段在源/目标两侧字段名、类型一致；若源是
user_id而目标是uid，需手动拖拽对齐，否则匹配失效 - 复合唯一索引（如
(tenant_id, external_id)）需同时勾选两个字段为匹配项，只勾一个等于没设 - SQL Server 用户注意：Navicat 底层用
MERGE实现，不支持批量 UPSERT 语法，大数据量（>5 万行）会明显变慢
MySQL 下「更新」模式实际走 INSERT … ON DUPLICATE KEY UPDATE
Navicat 对 MySQL 使用 INSERT ... ON DUPLICATE KEY UPDATE 语句，前提是目标表有主键或唯一索引，且你已正确设置匹配字段。它不会执行先 SELECT 再判断的两步逻辑，性能较好。
容易踩的坑是字段值被意外覆盖：比如你只勾了 id 为匹配字段，但源数据中 status 字段为空，Navicat 会把目标表原有 status 值更新为 NULL。
- 检查「字段映射」页中非匹配字段的「更新」开关是否开启——默认全开，如只需更新部分字段（如仅同步
updated_at和amount），要把其他字段的更新勾去掉 - 时间戳字段推荐用
NOW()或UTC_TIMESTAMP()替代源值，避免因源库时区不准导致时间倒退 - 若目标表有
NOT NULL字段无默认值，且源数据对应列为 NULL，整个语句会失败，需提前补默认值或清洗数据
PostgreSQL / SQL Server 不支持自动 UPSERT，得靠「更新」+「插入」分两步
PostgreSQL 本身支持 INSERT ... ON CONFLICT，但 Navicat 导入向导不暴露该语法控制权；SQL Server 更只能靠 MERGE。两者在导入流程中均无法做到单次操作原子性完成“存在更新、不存在插入”。
典型表现：导入中途报错 ERROR: duplicate key value violates unique constraint（PG）或 Error 2627（SQL Server），任务中断。
- PostgreSQL 用户可改用「数据传输」功能替代导入向导，在高级选项中启用
ON CONFLICT DO UPDATE（需 Navicat 16+，旧版不支持） - SQL Server 用户必须接受「更新」模式的局限：它只更新已有行，不插入新行；要实现完整 UPSERT，需先运行一次「更新」，再另起一次「追加」并勾选「忽略重复项」（但后者在 SQL Server 中无效，所以实际只能手动补 INSERT）
- 跨库迁移（如 MySQL → PG）时，Navicat 不会自动转换 UPSERT 语义，字段映射出错概率高，建议先导出为 SQL 文件，人工补写
ON CONFLICT逻辑
别信「忽略重复项」能代替 UPSERT
「忽略重复项」只跳过冲突记录，不做任何更新，和“存在更新”完全相反。它只在 MySQL/PostgreSQL 的「追加」模式下生效，且依赖主键/唯一索引；对 SQL Server 是灰色不可用状态。
很多人以为勾了这个就万事大吉，结果发现数据没更新、也没报错，日志只显示“成功导入 X 行”，X 还比预期少——其实是所有冲突行都被静默跳过，连日志提示都没有。
- 确认你的需求：要的是“同步变更”还是“只保最新快照”？前者必须用「更新」模式，后者才考虑「忽略重复项」+ 全量重导
- 测试时务必用小数据集验证：插入一条已存在主键的记录，看目标表对应字段是否真被更新，而不是原样不动
- 生产环境上线前，先在测试库执行一次带
--dry-run（如用命令行）或导出为 SQL 文件预览语句，看清 Navicat 到底生成了什么
