迁移后必须做数据校验，核心是比对源库和目标库的记录数、关键字段值、业务逻辑结果三类内容；需逐表校验行数与主键去重数、表结构、抽样字段MD5值，并验证外键完整性、聚合结果及业务逻辑一致性。
迁移后必须做数据校验，否则无法确认新库是否完整、准确、一致。核心是比对源库和目标库的记录数、关键字段值、业务逻辑结果三类内容，不能只看行数。
核对表级基础一致性
先快速验证每张表是否存在、行数是否一致，这是最基础的兜底检查。
- 用 SELECT COUNT(*) 分别查源库和目标库各表总行数，逐表比对；注意加 WHERE 条件过滤掉测试数据或已归档数据，避免误判
- 检查主键/唯一键数量是否一致，防止重复写入或去重丢失（例如用 SELECT COUNT(DISTINCT id)）
- 对比表结构：字段名、类型、长度、默认值、索引（尤其主键和外键），可用 SHOW CREATE TABLE 导出后文本比对
抽样校验关键字段内容
全量比对所有字段不现实，应聚焦业务强依赖字段，按主键或时间范围分批抽样。
- 选取高频查询字段（如订单号、用户ID、金额、状态、创建时间）做 MD5 摘要比对，例如：
SELECT id, MD5(CONCAT(id, order_no, amount, status)) AS chksum FROM orders ORDER BY id LIMIT 1000 - 对时间敏感表（如日志、流水），按日期分区抽样，比如查某天全部记录的 checksum 总和是否一致
- 避免直接 SELECT * 全字段拼接，容易因 NULL、空格、时区、字符集差异导致假不一致；建议显式列出字段并用 COALESCE 处理 NULL
验证业务逻辑与关联关系
数据不是孤立的，要检验外键约束、统计结果、上下游一致性等真实使用场景。
- 检查外键引用完整性：比如订单表 user_id 是否都在用户表存在，可用 LEFT JOIN + IS NULL 快速定位孤儿记录
- 运行典型聚合 SQL 对比结果，如“每个用户的订单总数”“每日成交金额”“状态分布比例”，结果必须完全一致
- 若涉及分库分表或读写分离，需在目标环境模拟真实应用请求路径，观察返回结果是否与旧库一致
自动化校验与持续监控
人工比对效率低且易漏，上线前应建立轻量校验脚本，并在迁移后短期保留双跑能力。
- 用 Python 或 Shell 写脚本，自动遍历库中所有表，执行 count + checksum 抽样，生成差异报告（推荐使用 pt-table-checksum 工具，支持增量校验和跨实例比对）
- 迁移后 24–72 小时内开启双写或影子流量，让部分真实请求同时写入新旧库，再比对关键结果
- 将核心校验项加入监控项，比如“订单表行数偏差 > 0.1%”触发告警，避免后续同步异常未被发现
