数据迁移双写校验：两边都写成功，不代表数据一致

数据迁移双写校验：两边都写成功，不代表数据一致

大规模数据迁移中，双写是常见过渡方案。旧库写一份，新库写一份，等校验通过后切流。听起来稳，但双写成功不等于数据一致。写入顺序、重试、幂等、字段转换、异步延迟、部分失败，都可能制造差异。

数据迁移最怕“看起来都成功”。校验必须比写入更严谨。

一、双写链路要记录状态

flowchart TD A[Write Request] --> B[Old Store] A --> C[New Store] B --> D[Write Log] C --> D D --> E[Consistency Checker]

每次双写要记录 old 成功、新成功、重试次数、幂等键和错误码。没有写入日志，后面校验只能大海捞针。

二、幂等键是底线

重试是必然发生的。没有幂等键，重复写入或乱序覆盖会让差异越来越隐蔽。

CREATE TABLE migration_write_log ( request_id VARCHAR(64) PRIMARY KEY, biz_id VARCHAR(64), old_status VARCHAR(16), new_status VARCHAR(16), retry_count INT, updated_at TIMESTAMP );

校验时可以先从 write log 找异常，再做全量抽样比对。

三、字段转换要可逆或可解释

迁移常伴随 schema 变化。字段拆分、类型转换、枚举重命名都可能引入差异。

field_mapping: old_status: 0: pending 1: paid 2: closed amount_cent: target: amount transform: "divide_by_100"

映射规则要版本化。否则发现差异时，不知道是数据错了，还是转换规则变了。

四、校验要分层

先做行数和 checksum，再做主键抽样，再做业务字段深比对。核心表还要做增量校验。

validation_layers: row_count checksum_by_range primary_key_sample business_field_compare incremental_replay_check

只看总行数没有意义。两边行数一样，也可能每一行都不一样。

校验还要处理时间窗口。双写期间数据持续变化，如果新旧两边读取时间不一致，会制造假差异。可以用版本号、binlog 位点或快照时间固定校验边界。

validation_boundary: old_binlog_pos: mysql-bin.000123:456789 new_checkpoint: ckpt_20260703_1000 compare_after_replay: true

没有一致的比较边界，校验结果只能说明“某一刻看起来不一样”，不能说明迁移逻辑错在哪里。

五、总结

数据迁移双写成功不代表一致。必须记录双写状态，使用幂等键，版本化字段映射，并做分层校验。

迁移工程里，搬数据只是前半段。证明数据真的一致，才是后半段，也是更难的一段。

切流前最后要做反向抽样：从新库随机抽主键回查旧库，再从旧库随机抽主键回查新库。两个方向都通过，可信度才更高。

迁移期间所有差异都要可解释。解释不了的差异，哪怕比例很低，也不应该被平均数掩盖。

低比例差异落到核心客户身上，就是完整事故。

校验不能只看比例，还要看影响面。