Navicat无真正双向同步，需分两次单向操作：先A→B（启Insert/Update，禁Delete），再B→A（仅Insert）；Key Mapping须完整映射主键或唯一键，否则触发重复插入；同步不可逆，执行前须备份。
双向同步不是一键开关，而是两次独立操作
navicat 本身没有「双向同步」模式，所谓双向，本质是手动执行两次单向同步：先 a→b，再 b→a。如果直接勾选 insert + update + delete 并来回跑，结果必然是互相覆盖、主键冲突、数据错乱。
常见错误现象：Duplicate entry '1001' for key 'PRIMARY'、某张表同步后行数暴涨或清零、时间戳字段反复被重写。
- 第一次同步（A→B）应只勾选
Insert records和Update records，禁用Delete records—— 避免误删 B 库中独有的数据 - 第二次同步（B→A）只勾选
Insert records，不勾Update records—— 否则 A 库刚改过的记录会被 B 库旧值覆盖 - 两次同步的
Key Mapping必须一致，且必须映射到主键或业务唯一键（如order_no），否则 Navicat 会把同一行判成多条新记录反复插入
冲突行怎么判断谁该留、谁该丢？
Navicat 不自动合并冲突，它只告诉你“源和目标同键但字段不同”。你得靠业务逻辑定主从，不能靠点击顺序猜。
典型场景：用户表中 ID=123 的记录，在 A 库 email 是 alice@old.com，在 B 库是 alice@new.com；A 是生产库，B 是客服系统录入端。这时你得人工确认：以 A 库为准，B 库的修改应走正式工单流程，不能直接同步覆盖。
- 进
Compare & Preview界面，点开具体表 → 切换到底部Difference标签页，逐行看哪些字段标红（即差异字段） - 右键某行 →
Exclude from synchronization可临时跳过，适合少量争议数据 - 若冲突集中出现在某几张表，建议导出预览 SQL，用文本编辑器搜索
INSERT INTO `user`或UPDATE `user`，人工核对后再执行
为什么勾了 Update 还报 Duplicate 错误？
这不是策略没生效，而是 Navicat 在判断“是否已有该键”时失败了 —— 它依赖 Key Mapping，而这个映射一旦错，Update 就退化成 Insert。
比如表有复合主键 (tenant_id, order_id)，但你在 Key Mapping 里只勾了 order_id，Navicat 就认为所有 order_id=1001 的记录都是“新行”，于是对每个租户都执行 INSERT，必然触发 Duplicate entry '1001' for key 'uk_order_id'。
- 进 Step 2 的
Key Mapping，确认勾选的是完整主键或唯一索引列，不能只选一个字段 - 检查源/目标表中对应键字段的类型是否一致：一边是
BIGINT，一边是INT，可能导致隐式转换失败，Navicat 误判为“不存在” - 如果表无主键，Navicat 默认用所有字段比对，极易误判；此时必须手动指定业务唯一键，否则放弃双向同步，改用日志或 CDC 工具
同步完发现数据不对，还能回滚吗？
不能。Navicat 数据同步不生成事务包裹的原子脚本，也不提供反向 SQL。一旦执行，INSERT/UPDATE/DELETE 就实时落库。
最稳的做法是：同步前在目标库做快照级备份（如 mysqldump --single-transaction），或至少确保 binlog 开启且保留足够天数。别指望 Navicat 自带“撤回”按钮。
- 执行前务必取消勾选
Synchronize data选项，纯结构同步阶段绝不会触发主键冲突 - 勾选
Skip duplicate key errors看似省事，但它等效于INSERT IGNORE，冲突行静默丢弃，连 warning 都可能被日志级别过滤掉 - 真正需要审计的场景，宁可中断报错，也不要开跳过——报错才是发现问题的信号，静默才是数据丢失的开始
