必须勾选「比较所有记录」，否则Navicat仅比对主键存在性而忽略字段值差异，导致更新操作漏判；预览页可直观查看具体行及字段级差异，但需注意字符集、时区不一致会引发假差异，真实跳过原因须查同步完成后的「信息日志」。
同步前必须勾选「比较所有记录」
默认情况下，navicat 的「数据对比」只比对主键是否存在，不会检查字段值是否一致——这意味着即使两行主键相同、但 updated_at 或 status 值不同，也会被标记为“无差异”。必须在对比配置第二步手动勾选 比较所有记录，否则后续同步只会做 insert/delete，漏掉 update。
常见错误现象：预览页显示“更新 0 行”，但实际目标表字段值明显落后于源表。原因基本就是没勾这个选项。
- 若表无主键或唯一键，Navicat 会退化为全字段逐行比对，速度极慢且结果难定位；建议提前加
PRIMARY KEY或UNIQUE索引 - 勾选后比对耗时上升，但这是必要代价；数据量大时可先在测试库验证逻辑
预览页里能直接看到哪几行要改、改什么字段
进入「数据同步」向导后，别急着点「运行」，先到预览页（点击「下一步」直到出现表格列表）。这里显示的是 Navicat 根据比对结果生成的真实操作清单：插入 X 行、更新 Y 行、删除 Z 行。
点击任意表名，底部窗格立刻展开源 vs 目标数据行，不同字段值会用黄色背景高亮。这不是模拟，是已计算出的最终动作。
- 如果某行只有
updated_at字段差异，大概率是业务自动更新，右键该行 →排除此项即可跳过 -
插入 0 行、更新 0 行、删除 N 行表示目标库有冗余数据，需人工确认是否应清理 - 预览不显示 WHERE 条件细节，无法区分“因主键冲突跳过”和“因字段值相同忽略”——真要看跳过原因，得翻同步完成后的「信息日志」页
字符集与时区不一致会导致假差异
Navicat 不会在界面提示“差异由字符集引起”，但 utf8mb4 和 utf8 对同一中文字符串的二进制表示不同，会被标为“字段值不同”；同理，TIMESTAMP 字段若一方存 UTC、一方存本地时间，也会高亮为差异。
排查方法：在两个库分别执行 SHOW CREATE TABLE table_name，比对 CHARACTER SET 和 COLLATE；再查 SELECT @@time_zone, @@system_time_zone 确认时区设置。
- 字符集不一致时，要么统一改为目标库字符集，要么在 Navicat 连接设置中强制指定
charset=utf8mb4 - 时间字段差异优先检查应用层写入逻辑——是否统一用 UTC 写入？避免在数据库层做时区转换
- 临时规避：在同步前手动把目标库相关字段设为 NULL 或统一值，再比对，可快速验证是否为纯时区/字符问题
同步失败后，关键线索藏在「信息日志」里
即使开了 使用 INSERT IGNORE，预览页也不会告诉你哪几行被跳过了。真正记录跳过行为的地方是同步完成后的「信息日志」页，每条语句都会附带真实执行反馈：
Duplicate entry '105' for key 'PRIMARY' 表示主键冲突被忽略；Data truncated for column 'price' at row 1 表示精度丢失；Incorrect datetime value 往往是时区或格式问题。
- 日志里每条 SQL 都带行号和表名，可直接复制出来在目标库手动执行，观察报错细节
- 若大量报错，别反复重试，先停住，根据日志高频错误类型反推配置问题（比如批量
Invalid default value就要检查sql_mode） - Navicat 不保存历史日志，关掉窗口就丢——发现异常第一时间截图或复制文本
updated_at 被标为差异，说明业务逻辑本身就在持续写入，这时该考虑的是同步策略调整（比如过滤掉时间戳字段），而不是每次手动排除。
