Navicat 17 数据同步非修复工具，而是单向比对+脚本生成器，必须明确源库（还原前）与目标库（刚还原），确保主键定义、字符集（utf8mb4）、字段映射一致，预览结果受事务和统计误差影响，生成脚本需手动加固事务、外键、分批逻辑。
还原后数据不一致，先别急着重导
navicat 17 的 data synchronization 不是“修复工具”，而是单向比对+脚本生成器。它不会自动识别“这是备份还原后的差异”，所有同步动作都依赖你明确指定哪边是权威源（比如还原前的源库）、哪边是目标（刚还原的库）。如果 source 和 target 选反了，它会把脏数据刷回源库。
执行同步前必须确认的三件事
否则预览里一堆 Duplicate entry 'X' for key 'PRIMARY' 或 Invalid default value for 'updated_at' 就是必然结果：
- Source 必须设为还原前的原始库（或结构/数据快照库），Target 是刚还原完的库
- 两张表的主键/唯一键定义必须完全一致：用
SHOW CREATE TABLE对比两边 DDL，特别注意AUTO_INCREMENT值、ENGINE类型、COLLATE是否相同 - 目标库连接的字符集必须设为
utf8mb4（检查「连接属性 → 高级 → 字符集」），否则中文字段比对会误报差异
预览阶段最容易踩的坑
点 Compare&Preview 后看到统计数字，不代表真实差异——它只基于当前快照读取，不感知源表是否正在被写入：
- 源表在同步过程中有写入？
information_schema.INNODB_TRX里有未提交事务？那预览结果就不可信 - 别信右下角显示的“行数”，
TABLE_ROWS在 InnoDB 下误差常达 40%~50% - 字段映射没手动绑定？比如源表字段叫
user_name，目标表叫username，Navicat 默认不匹配，结果就是“0 differences found”但实际全错 - 时间字段精度不一致？源库存
DATETIME(3)，目标库是DATETIME（秒级），Navicat 会截断再比，毫秒差异直接被掩盖
生成脚本后不能直接跑
Generate Synchronization Script 生成的 SQL 是裸语句，没有事务包装，也没有错误跳过逻辑：
- 默认
WHERE条件用的是主键字段名，如果目标表主键已从id改成uid，脚本会执行失败，必须手动替换 - 勾选了
Include DROP/CREATE statements？多数还原场景应取消，否则可能误删目标表 - 脚本里没加
SET FOREIGN_KEY_CHECKS = 0;？外键约束会拦住INSERT或UPDATE，得自己补 - 大表同步建议拆成小批次：用
WHERE id BETWEEN X AND Y分段执行，避免锁表太久
真正难的不是点按钮，而是判断哪些差异该同步、哪些该保留、哪些根本不是差异——比如 ENUM 值列表扩展、列顺序微调、空格/大小写设置没开，这些都会触发误报，但改了反而破坏业务逻辑。
