源目标对账是什么
对账（一致性校验）用来回答「搬过来的数据和源端一样吗」。常用三层递进：行数对账做粗筛、主键集合比对找单侧缺失与多余、按主键分桶的校验和比对定位到差异范围。校验要按业务主键口径而不是物理行数（软删除、重复行、乱序都会干扰结论），大表分桶并行、按时间窗缩小范围，差异必须能定位到具体的主键区间才具备修复价值。
基本信息
| 适用场景 | 数据同步、迁移、整库复制后的正确性验收 |
|---|---|
| 三层方法 | 行数 → 主键集合 → 分桶校验和，逐层定位 |
| 分桶方式 | 按主键取模或按范围分片，两侧用同一分桶规则 |
| 失败定位 | 差异桶再按主键二分定位到具体键值范围 |
| 结果留存 | 对账结果落表并保留历史，用于判断是首次还是反复出现 |
典型使用场景
- 迁移验收：迁移完成后按表逐个出具对账结论
- 日常巡检：核心表每天比对关键字段校验和，及早发现同步中断
- 故障后核对：增量链路中断恢复后，确认中间缺失区间已被补齐
- 回刷验收：回补任务完成后核对结果是否与预期一致
- 口径排查：两侧数字不一致时判断是数据差异还是口径差异
行数与校验和（源端示例）
行数与校验和（源端示例）
-- 粗筛：行数 + 关键字段校验和（同一 SQL 在目标端执行后比对）
SELECT COUNT(1) AS cnt,
BIT_XOR(CRC32(CONCAT_WS('#', order_id, CAST(amount AS CHAR), status))) AS sig
FROM dw.orders
WHERE update_time >= '2026-10-01' AND update_time < '2026-10-11';
-- 分桶校验和：桶号由主键取模得到，两侧规则必须完全一致
SELECT MOD(order_id, 16) AS bucket,
COUNT(1) AS cnt,
BIT_XOR(CRC32(CONCAT_WS('#', order_id, CAST(amount AS CHAR), status))) AS sig
FROM dw.orders
GROUP BY MOD(order_id, 16)
ORDER BY bucket;主键集合比对
主键集合比对
-- 目标缺哪些主键（源有目标没有）
SELECT s.order_id FROM src_orders s
LEFT JOIN dw.orders t ON t.order_id = s.order_id
WHERE t.order_id IS NULL
LIMIT 100;
-- 目标多哪些主键（目标有源已删）
SELECT t.order_id FROM dw.orders t
LEFT JOIN src_orders s ON s.order_id = t.order_id
WHERE s.order_id IS NULL
LIMIT 100;三层方法读法
| 层次 | 能发现什么 | 局限 |
|---|---|---|
| 行数 | 整体缺失或翻倍，几秒即可得出结论 | 行数相等仍可能有同数不同值 |
| 主键集合 | 单侧缺失与多余的具体键 | 只看键不看内容，字段错位查不出 |
| 分桶校验和 | 同一批键里内容是否一致，并能缩小到桶 | 桶内仍需二分；两侧函数与类型必须一致 |
| 抽样明细 | 最终确认真实差异内容 | 成本高，只对差异键执行 |
增量链路的对账要留出在途窗口：比对截止时间取「两侧都已处理完」的时刻，并排除正在写入的最新几分钟，否则延迟写入会被误判为缺失。
两侧的排序、字符集、类型转换与 NULL 处理必须完全一致，否则哈希天然不同，会产出大量假差异，反而掩盖真实问题。