企业级数据迁移校验必须覆盖结构层、数据层和语义层三层，且需在增量迁移中通过终态快照比对与双写比对保障一致性，同时实现可配置化、自动归因与可审计的闭环自动化。
企业级数据迁移不是“导出再导入”这么简单，校验环节直接决定成败。一次没校验清楚的迁移，可能在上线后数周才暴露数据错位、主键冲突或时间戳偏移，修复成本是事前投入的5倍以上。关键不在“有没有校验”，而在“校验是否覆盖真实业务语义”。
校验必须分层：从字节到业务逻辑
只比对行数或MD5是危险的简化。企业级校验需覆盖三层：
- 结构层：表名、字段名、字段类型、长度、是否为空、索引与约束是否完整重建（尤其注意Oracle的NUMBER(p,s)到MySQL DECIMAL的精度映射）
- 数据层：非空主键/唯一键记录数一致；按分区或时间范围抽样比对关键字段（如订单ID、金额、状态码）；使用校验和（如CRC32或SHA256）验证大文本/二进制字段
- 语义层：执行业务规则脚本——例如“所有已完成订单的支付时间不能晚于发货时间”“同一用户当日下单数≤100”——这些逻辑无法靠数据库自身约束捕获，必须单独验证
增量迁移中的校验陷阱与应对
全量迁移可停机校验，但生产系统多采用“全量+持续增量”模式，此时校验极易失效：
- 源端写入未同步完成时就触发最终校验，导致目标端“看起来一致，实则缺数据”
- 增量日志解析丢失事务边界（如MySQL binlog中跨语句的UPDATE+INSERT组合被拆开）
- 时钟不同步造成“未来时间戳”数据被过滤或排序错乱
建议做法：在切换流量前，先暂停源端写入（或锁定关键表），执行一次“终态快照比对”；同时启用双写比对服务，在新旧系统并行期间实时核对相同输入产生的输出是否一致。
自动化校验不是加个脚本，而是构建闭环
人工跑SQL查总数、导Excel比对，既慢又不可重复。企业级方案应具备：
- 校验任务可配置化：通过JSON/YAML定义校验对象、字段、阈值、抽样率（如“用户表抽样5%，金额字段误差容忍±0.01%”）
- 失败自动归因：不只是报“不一致”，还要定位到具体表、分区、甚至行号（借助ROWID或业务主键）
- 结果可审计：每次校验生成带签名的报告，包含时间戳、操作人、环境标识、校验工具版本，满足等保与GDPR留痕要求
风险控制要前置到校验设计阶段
很多团队把“回滚”当成兜底手段，但真实场景中，90%的数据回滚失败源于校验缺失：
- 未校验外键引用完整性，回滚后出现孤儿记录
- 未识别序列/自增ID冲突，回滚重放时主键重复报错
- 未检查时区与时间函数转换（如SYSDATE→NOW()），导致历史报表时间偏移
因此，校验清单必须与回滚预案联动。例如：若校验发现目标库中某张流水表缺失最近2小时数据，则回滚步骤必须包含“从源库补取该时段binlog并重放”，而非简单还原备份。
