数据迁移双写校验两边都写成功不代表数据一致大规模数据迁移中双写是常见过渡方案。旧库写一份新库写一份等校验通过后切流。听起来稳但双写成功不等于数据一致。写入顺序、重试、幂等、字段转换、异步延迟、部分失败都可能制造差异。数据迁移最怕“看起来都成功”。校验必须比写入更严谨。一、双写链路要记录状态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没有一致的比较边界校验结果只能说明“某一刻看起来不一样”不能说明迁移逻辑错在哪里。五、总结数据迁移双写成功不代表一致。必须记录双写状态使用幂等键版本化字段映射并做分层校验。迁移工程里搬数据只是前半段。证明数据真的一致才是后半段也是更难的一段。切流前最后要做反向抽样从新库随机抽主键回查旧库再从旧库随机抽主键回查新库。两个方向都通过可信度才更高。迁移期间所有差异都要可解释。解释不了的差异哪怕比例很低也不应该被平均数掩盖。低比例差异落到核心客户身上就是完整事故。校验不能只看比例还要看影响面。