大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
数据迁移完成后，业务方问的第一个问题往往是：“数据都过来了吗？跟原来一样吗？”你心里可能也没底。全量导出导入过程中，可能丢失几条；CDC同步过程中，可能漏掉几个变更；新老库的隐式类型转换，可能导致数据值变了。这些坑，不提前校验，上线后就会变成生产事故。
今天聊聊：迁移后如何验证数据一致性？有哪些校验方法？怎么选工具？
一、为什么数据一致性校验这么重要？
- 数据丢失：迁移过程中网络中断、目标端写入失败，可能导致部分数据未同步。
- 数据变更：源库和目标库的数据类型、字符集、时区等差异，可能导致数据值发生改变（如时间戳精度丢失、空字符串变NULL）。
- 业务逻辑错误：源库某些约束（如外键、唯一性）在目标库未正确创建，导致后续写入出现脏数据。
数据一致性校验的目标就是：确认源库和目标库的数据在迁移完成后完全一致，或至少在可接受的差异范围内。
二、三种主流校验方法
1. 全量校验
对源库和目标库的全部数据进行逐行对比。最可靠但成本最高。
实现方式：
- 导出对比：将源库和目标库的数据导出为文件（如CSV），用diff工具对比。适合小数据量（<1GB）。
- 行数+关键字段哈希：对每个表，计算行数、关键字段的MD5或CRC32值，两边对比。速度快，但不能保证每行完全一致。
- 分块哈希：将一个大表分成多个块（如按主键范围），每块计算哈希，对比差异块后再逐行对比。平衡了速度和精度。
常见工具：pt-table-checksum（Percona Toolkit）、开源脚本、商业同步工具自带的校验模块。
2. 增量校验
针对CDC同步过程中的增量变更进行校验。通过记录每个变更的日志序列号（如binlog position），在目标端回放后对比影响的行数。
实现方式：在CDC工具中加入“校验点”，定期暂停同步，对比当前时刻源和目标的数据快照。如果一致，继续同步；如果不一致，触发告警并记录差异行。
适用于持续同步的场景（如双活、容灾）。
3. 抽样校验
对于超大表，全量校验成本太高。抽样校验可以基于主键范围、随机采样等方式抽取部分数据进行对比，评估整体一致性。
优点：快；缺点：不能100%保证，适合对一致性要求不是极高、或数据量极大的场景。
三、校验方案的对比
| 方案 | 覆盖度 | 性能开销 | 适用场景 | 能否发现所有差异 |
|---|---|---|---|---|
| 全量逐行对比 | 100% | 极高 | 小表、核心表 | 是 |
| 分块哈希校验 | 100% | 中高 | 中大表，较常用 | 是 |
| 行数+关键哈希 | 部分 | 低 | 快速筛查 | 否（可能漏差异） |
| 增量校验（校验点） | 增量部分 | 中 | 持续同步场景 | 是（对增量部分） |
| 抽样校验 | 抽样比例 | 低 | 超大表、非核心 | 否 |
在实际项目中，推荐组合使用：先用行数+关键哈希快速筛查所有表，找出可疑的表；再对可疑表进行分块哈希校验；最后对差异块进行逐行对比。
四、主流校验工具
- pt-table-checksum：Percona Toolkit出品，支持在线校验，对业务影响小，通过在主库执行checksum查询，将结果与从库对比。适合MySQL主从/迁移校验。
- 自定义脚本：用Python/Java编写，灵活性高，适合复杂校验逻辑（如跨异构数据库）。
- 商业同步工具自带校验：如KFS数据同步软件，内置了多维度一致性校验体系（结构比对、全量数据MD5校验、增量变更追踪）。在迁移完成后可以一键触发校验任务，自动生成差异报告，并支持断点续传校验。对于异构数据源（Oracle->KingbaseES），KFS还能自动转换数据类型后进行比对，避免因类型差异导致的误报。
五、完整校验流程
- 迁移前准备：记录源库的表结构、约束、索引、行数基线。
- 全量迁移后：立即对迁移完成的表进行行数校验 + 关键字段哈希校验。如果一致，进入下一步；如果不一致，重新迁移或手动修复。
- 增量同步期间：设置定期校验点（如每小时一次），对比当前时刻的关键表数据。
- 灰度切换前：进行一次全量分块哈希校验，确认最终一致性。
- 切换后验证：在新库上运行业务的核心查询，对比结果与老库的快照是否一致。
- 持续校验：迁移完成后一周内，每日运行抽样校验，观察是否出现差异。
六、常见问题与解法
- 问题：校验太慢，影响业务
解法：选择业务低峰期执行；使用分块并行校验；对超大表使用抽样校验。 - 问题：异构数据库类型不一致导致误报
解法：在工具中配置类型映射规则（如Oracle的NUMBER->KingbaseES的NUMERIC）。KFS等工具内置了常见类型映射，可以避免这类误报。 - 问题：增量同步持续有变更，无法静态校验
解法：使用在线校验工具（如pt-table-checksum）或从备库/快照读取数据，避免锁定主库。
七、价值总结
数据迁移不是“搬运工”的工作，而是“快递员+质检员”的工作。跑通了全量、追平了增量，不代表数据就正确了。建立自动化、持续的数据校验机制，是保障迁移质量的最后一道防线。用好校验工具，你可以在业务方发现问题之前，自己先发现并修复差异。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
