数据迁移校验是贯穿全生命周期的质量控制中枢，需分层验证结构、数据、逻辑三类一致性，并内嵌于自动化流程，满足可审计、可回溯与协同验证要求。
数据迁移校验不是“导完再查一遍”那么简单，而是贯穿迁移全生命周期的质量控制中枢。它决定着新系统能否真正接棒——不是看起来像，而是每一笔业务、每一个字段、每一条关联关系都跟源端严丝合缝。
校验必须覆盖三类核心一致性
只比总数或抽样几条记录，大概率漏掉关键缺陷。真正有效的校验要分层验证：
-
结构一致性：表名、字段名、数据类型、长度、是否为空、主键/索引定义是否与目标库设计完全对齐。例如 Oracle 的
NUMBER(10,2)映射到 PostgreSQL 应为NUMERIC(10,2)，而非DECIMAL或FLOAT，否则可能引发精度丢失；TiDB 不支持LONG类型，需提前转为TEXT并确认应用层兼容性。 -
数据一致性：不只是行数相等，更要验证内容准确。重点包括：主键/唯一键值是否完整无重复、外键引用是否全部可解析、NULL 值分布是否符合业务语义（如“创建时间”不应为 NULL）、金额类字段求和结果是否精确匹配（建议用
SUM(CAST(... AS DECIMAL))避免浮点误差）。 - 逻辑一致性：这是最容易被忽略的层面。比如订单表中“实付金额 = 商品总价 − 优惠券 − 运费 + 税”，该公式在新库中是否仍能通过计算复现；又如状态流转依赖触发器或存储过程（Oracle PL/SQL），迁到 TiDB 或 PostgreSQL 后若改用应用层处理，必须确保所有分支路径都被覆盖且时序正确。
校验方法不能只靠人工SQL写脚本
手动写比对 SQL 效率低、易出错、难复用，尤其面对数百张表、跨库异构场景。现代化交付要求校验能力内嵌于流程：
- 使用带位点追踪的同步框架（如基于 Kafka 的 KFS）时，校验服务应能按 binlog 位点或事务 ID 拉取源目标两端对应批次数据，逐字段哈希比对，自动定位差异行并生成修复建议。
- 对于停机迁移，推荐采用“分段校验+滚动验证”：先校验基础码表（字典、区域、用户角色等静态数据），再校验核心交易流水，最后校验汇总报表。每段通过后才推进下一段，避免最后才发现主键冲突导致返工。
- 工具链需支持可视化差异报告，包含差异类型（缺失、冗余、值不一致）、影响表、样本数据、SQL 修复语句，直接对接 DevOps 流水线，失败即阻断发布。
现代化软件交付对校验提出新标准
当前金融、政务等关键行业已将数据校验纳入准入红线，不再接受“基本一致”的模糊结论：
- 可审计性：所有校验动作、参数、时间戳、执行人、环境信息必须自动留痕，输出符合等保三级或金融级监管要求的审计日志。
- 可回溯性：一旦上线后发现数据问题，应能快速定位是哪一轮同步、哪个表、哪条记录未同步成功，并关联到原始 binlog 位置或迁移批次号。
- 协同验证机制：校验不能只由 DBA 完成。需联合 ISV 提供业务规则校验包（如医保结算中的药品目录匹配逻辑）、前端团队提供关键页面数据快照、测试团队运行真实交易链路回归，形成多维度交叉验证。
校验不是迁移的收尾动作，而是驱动迁移设计的起点。从一开始就把校验规则反向注入建表脚本、ETL 映射逻辑和同步策略里，才能让“零误差切换”成为可落地的目标，而不是验收时的侥幸承诺。
