数据迁移校验是贯穿全生命周期的质量守门员，需分层执行全量比对、增量追踪与业务探活，并建立差异归因、阈值驱动决策及回退锚点机制。
数据迁移校验不是“导完再比一下”就完事，而是贯穿迁移全生命周期的质量守门员。它既要验证数据搬得“全不全”，也要确认搬得“对不对”，更要保障业务用得“稳不稳”。真正落地有效的校验，必须拆解为可执行、可度量、可回溯的动作。
校验不是最后一步，而是从评估阶段就开始嵌入
很多人把校验当成迁移执行完才启动的收尾动作，结果发现差异时已无法定位是转换逻辑错、同步漏写、还是源端脏数据。正确的做法是从第一步就埋点：
- 在评估阶段，就明确每张核心表的校验维度：行数、关键字段聚合值（如金额sum、数量count）、主键分布、空值率、时间范围覆盖等；
- 在转换阶段，为每条SQL改造生成“语义等价用例”，例如原Oracle分页语句返回第101–110条记录，目标库对应改写后必须返回完全相同的数据集；
- 在迁移前，对源库快照打标——记录校验基线时间点、binlog位点或SCN，并保存该时刻的统计快照（如select count(*), sum(amount) from trade_order where create_time ）。
校验要分层：全量比对 + 增量追踪 + 业务探活
单一校验手段必然失效。高可用迁移要求三层交叉验证：
- 全量比对：使用专用工具（如KFS、SQL Data Compare）做表级/字段级逐行比对，重点覆盖主键、金额、状态、时间戳类敏感字段；注意跳过日志表、临时表、审计轨迹等非业务主干表，避免干扰；
- 增量追踪：在割接窗口期开启双写或CDC捕获，对比迁移中新增/变更记录是否100%同步，尤其关注事务边界（如转账类操作必须保证转出与转入同时出现在目标库）；
- 业务探活：用真实查询语句跑通核心业务链路，例如“查某用户近7天订单+支付+物流状态”，验证结果一致性，而非只看单表数据。这类探针应提前沉淀为自动化脚本，在每次校验轮次中自动执行。
发现差异不能只报“不一致”，必须能快速归因
校验工具报出10万条差异，如果无法快速判断是数据问题、映射问题还是时序问题，等于没校验。关键在于建立差异分类机制：
- 将差异分为三类：源端异常（如源库本身存在重复主键）、转换异常（如日期格式截断、NULL转默认值逻辑不一致）、同步异常（如网络抖动导致某批次丢失）；
- 每类差异绑定可追溯信息：源库记录ID、目标库对应ID、转换规则编号、同步批次号、执行时间戳；
- 对高频差异模式建白名单——例如某些报表表允许分钟级延迟，某些日志字段允许内容截断，但需经业务方签字确认并记录在案。
校验结果必须驱动决策，而不是堆报告
校验的价值不在生成一份PDF，而在支撑割接放行或暂停。因此校验结论必须满足三个硬条件：
- 有明确阈值：例如“核心交易表行数偏差≤0.001%、金额sum偏差=0、状态字段不一致率=0”才视为通过；
- 有责任人闭环：每项未通过项标注负责人（开发改逻辑、DBA补数据、业务确认容忍）、解决时限、验证方式；
- 有回退锚点：校验失败时，能立即调出最近一次合格校验快照，启动KReplay负载回放或基于备份快速回滚，而不是从头排查。
