Navicat 17 数据同步中的验证功能如何保证数据最终一致性

“验证”仅做连通性检查与本地模拟比对，不执行数据库操作；显示的增删改行数是计划动作而非实际结果，不校验外键、时区、业务逻辑等一致性，需人工核对Preview明细并补充同步后校验。

“验证”不是自动校验，只是执行前的差异预览

navicat 17 的「验证」（validate）按钮实际不触发任何数据库操作，它只做两件事：连接连通性检查 + 本地内存中模拟比对。所谓“保证最终一致性”，完全依赖你对预览结果的理解和后续人工干预。点击后弹出的窗口里显示的 insert、update、delete 行数，是 navicat 根据当前快照算出来的“计划动作”，不是已生效状态。

• 它不会访问目标库实时数据——如果目标库在你点击「验证」后、点击「部署」前被其他程序修改，预览结果就失效
• 它不校验外键约束是否满足——哪怕目标库父表缺失主键，「验证」仍显示成功，真正报错要等到执行时
• 时间字段若存在时区偏差（如源库用 NOW() 写入 UTC，目标库会话时区是 CST），「验证」阶段无法识别这种逻辑不一致，只会按字面值比对

真正起作用的是「Compare & Preview」里的字段级差异明细

比「验证」更有价值的是点击 Compare & Preview 后展开的每张表详情页。这里你能看到具体哪些行将被更新、哪几个字段值不同，高亮显示差异字段。这才是定位数据不一致的起点。

• 注意底部「Source」和「Target」标签页切换——必须手动核对两边字段值，不能只信“差异数量”
• 如果某字段显示为 NULL vs ''（空字符串），Navicat 默认判为不同；但 MySQL 在某些 sql_mode 下视二者等价，这会导致同步后业务逻辑异常
• 枚举字段（ENUM）值顺序不一致时，「Preview」可能把同一语义值（如 'active'）当成不同值，因为底层存储的是序号而非字符串

“验证通过”后仍需手动加校验环节

Navicat 不提供同步后自动校验功能。所谓“最终一致性”，必须靠你补上这一步：要么用内置的「数据内容对比」工具再跑一次，要么写 SQL 直查关键指标。

• 用「数据内容对比」前，务必确认两个连接都设了 utf8mb4 字符集，且勾选了 Ignore whitespace 和 Ignore case（尤其对 MySQL）
• 大表（>50 万行）别依赖图形界面比对——直接执行类似下面的 SQL 查主键存在但字段不一致的记录：

  SELECT 'mismatch' AS flag, t1.id, t1.name, t2.name FROM source_db.users t1 JOIN target_db.users t2 ON t1.id = t2.id WHERE t1.name != t2.name OR (t1.name IS NULL) != (t2.name IS NULL);

• 生成的同步脚本（勾选 Generate synchronization SQL script）一定要保存，失败时可逐条执行并加 SELECT COUNT(*) 中间校验

容易被忽略的关键点

「验证」环节最常被跳过或误读的，是它完全不感知业务规则。比如你同步订单表，源库 status 字段从 'paid' 改成 'shipped'，目标库同 ID 订单却是 'cancelled'——「验证」会照常生成 UPDATE，但业务上这可能是严重状态越级。这种一致性，只能靠你在预览时肉眼识别、或提前在 WHERE 条件里加 AND status IN ('paid', 'shipped') 控制范围。