校验方法论总览：全量校验、增量校验、抽样校验

数据一致性校验怎么做？说白了就三种路子：全量、增量、抽样。

我刚带团队那会儿，总觉得全量校验最靠谱，恨不得每次补数都跑一遍全量。结果呢？有一次补了 2TB 的客户历史数据，全量校验跑了整整 17 个小时，业务方催了三次，最后还因为校验时间太长导致补数窗口超时。嗯，从那以后我学乖了——没有银弹，只有场景。

这一章，我把这三种校验方法掰开揉碎讲清楚，再聊聊校验到底该看哪些维度。

全量校验：最笨，也最稳

全量校验，就是把源端和目标端的所有数据逐条比对。听起来简单，做起来坑不少。

我习惯把全量校验分成两个阶段：

1. 结构预检：先确认两边表结构一致——字段名、字段类型、字段顺序、主键定义。结构不对，后面比了也白比。
2. 数据比对：按主键排序后逐行比对。遇到大表，我会拆成多个分区并行跑，不然单线程能跑到天荒地老。

全量校验的优缺点很明显：

维度	说明
优点	覆盖率 100%，不漏任何一条数据；逻辑简单，容易自动化
缺点	耗时随数据量线性增长；对源端和目标端性能压力大；不适合实时场景
适用场景	首次补数、数据量小于 500 万行、业务要求零差错（如资金类）

增量校验：快，但有前提

增量校验只比对新增或变化的数据。你想想看，如果每天只补几万条增量数据，却要全量跑几千万条，那不是浪费资源吗？

增量校验的核心依赖是变更追踪机制。常见做法有三种：

• 时间戳字段：源表有 update_time 或 modified_date，按时间范围拉取增量数据比对。这是最常用的方式，但前提是业务系统必须保证时间戳准确更新。
• 日志解析：通过解析数据库的 binlog、redo log 或 WAL 日志获取变更记录。适合对源端无侵入的场景，但需要额外搭建日志采集组件。
• 版本号或序列号：源表维护一个自增的 version 字段，每次更新 version+1。校验时只拉取 version 大于上次校验值的记录。

增量校验的适用边界：

条件	说明
必须满足	源端有可靠的变更追踪机制；增量数据量远小于全量数据量
建议满足	补数频率高（如 T+1 甚至实时）；业务允许短时间的不一致窗口
不适合	源端没有时间戳或日志；历史数据回溯补数；监管审计要求全量对账

抽样校验：效率优先，赌一把

抽样校验，说白了就是用统计学方法代替穷举。数据量太大、全量跑不动，增量又没条件，那就抽一部分数据来验证。

我常用的抽样策略：

• 随机抽样：按主键或行号随机抽取 N 条记录。简单，但可能漏掉关键数据。
• 分层抽样：按业务维度（如日期、区域、产品类型）分层，每层按比例抽取。覆盖率比纯随机好很多。
• 边界值抽样：专门抽取最大值、最小值、空值、边界日期等特殊数据。很多 bug 都藏在边界里。
• 异常值抽样：抽取金额为负、数量为 0、时间戳异常等可疑记录。适合快速发现明显问题。

抽样校验的风险：

校验的维度：行数、金额、关键字段

不管用哪种校验方法，最终都要落到具体的校验维度上。我把它总结为三个层次：

维度	校验内容	常用方法	优先级
行数	源端和目标端记录总数是否一致	COUNT(*)，按分区或日期分组统计	最高
金额	数值型字段的汇总值、均值、极值是否一致	SUM、AVG、MAX、MIN，按业务维度分组	高
关键字段	业务主键、唯一标识、状态字段、时间字段是否一致	逐字段比对，或使用 MD5 校验整行	中

行数校验是最基础的。如果行数都对不上，后面的校验基本不用做了。我习惯在补数脚本里先加一行 SELECT COUNT(*) FROM source 和 SELECT COUNT(*) FROM target，行数不一致直接告警，不往下走。

金额校验是金融场景的命门。我见过最离谱的案例：源端金额字段是 decimal(18,2)，目标端误配成 decimal(18,0)，所有金额都被四舍五入了。行数校验完全正常，但金额差了十几万。所以，金额字段一定要做 SUM 比对，而且要比对到小数点后两位。

关键字段校验最灵活。你可以只比对主键、唯一索引、业务状态等核心字段，不用全量比对所有字段。适合数据量大但业务关注点集中的场景。

三种方法与三个维度的组合矩阵

我画了一张图，把校验方法和校验维度组合起来，方便你对照选择：

如何选择？我的决策框架

每次做补数方案，我都会问自己三个问题：

1. 数据量多大？ 小于 500 万行 → 全量校验；500 万到 5000 万行 → 增量或抽样；大于 5000 万行 → 必须抽样+增量组合。
2. 业务容忍度多高？ 资金类、监管类 → 全量校验，行数和金额必须 100% 一致；报表类、分析类 → 抽样校验即可，允许千分之一以内的误差。
3. 补数频率多高？ 一次性补数 → 全量校验；每日增量补数 → 增量校验；实时补数 → 增量校验+抽样校验兜底。