为什么数量总是对不上迁移完成后经常出现这样的对话研发说迁移成功。 测试说目标库数量少了。 业务说老系统界面不是这个数。 实施说源库 SQL 查出来又是另一个数。这通常不是谁错了而是口径不同。可能存在的口径差异源库原始行数 源库按业务字段去重后的数量 目标库明细数量 目标库按主键去重后的数量 老系统页面聚合后的数量 新系统页面过滤后的数量如果没有统一口径验收一定会反复争论。代码口径要明确写出来每个模块都要明确说明代码按什么规则迁移。例如实时dev_message当前去重口径是device_id data_time real_volume alarm_code diagnos rssi comm_voltage不参与去重meter_time SEQ gateway EUI 24 小时冻结值 source_key这个口径不写出来验收人员可能会把source_key或meter_time也算进去最后数量就不一致。dry-run 和 validate 也要同口径dry-run 用来预估数量。validate 用来验证结果。如果 dry-run、execute、validate 三套 SQL 口径不一致就会出现dry-run 说有 10 万 execute 写入 9 万 validate 又说缺失 1 万这类问题不一定是执行失败而是统计口径本身不一致。因此修改迁移逻辑时必须同步检查dry-run 统计 execute 写入 validate 校验 人工验收 SQL只改 execute不改 validate是很危险的。人工验收 SQL 要能复制执行生产验收时最好给实施和测试一组可直接复制的 SQL。SQL 里不要隐藏太多业务假设。例如实时数据可以提供-- 源库按迁移口径去重后的数量selectcount(*)source_distinct_countfrom(selectmeter_id,data_time,real_volume,alarm_code,diagnos,rssi,comm_voltagefromt_realtimedatawheremeter_idin(selectmeter_codefromas_meterwheredept_code目标部门编码)groupbymeter_id,data_time,real_volume,alarm_code,diagnos,rssi,comm_voltage)t;目标库可以提供selectcount(*)target_countfromdev_message dminnerjoinmig_emrc_meter_scope sons.meter_codedm.device_idwheres.business_account客户andjson_valid(dm.data_details)1andjson_unquote(json_extract(dm.data_details,$.source))EMRC;源库和目标库必须按同一口径对比。验收 SQL 要避免和代码漂移代码改了验收 SQL 也要改。例如实时去重从旧口径source_key改成新口径device_id data_time real_volume alarm_code diagnos rssi comm_voltage那么验收 SQL 也必须同步改。否则生产上会出现代码是新口径 同事拿旧 SQL 查源库 数量对不上 大家以为迁移错了验收 SQL 应该随代码提交一起更新。每个模块都应该有一组验收 SQL建议至少覆盖主档设备数量 实时 dev_message 数量 冻结 dev_daily_freeze 数量 告警 alarm_record_new/list 数量 WalkBy rm_record/rm_task/rm_book/rm_plan 数量 latest 表数量 last_report_time 修复情况对于存在去重的模块还要额外提供源库原始数量 源库去重数量 目标库数量 目标库重复组数量只看一个 count 是不够的。验收 SQL 也要记录异常解释有些数量不一致是合理的。例如实时数据按业务口径去重目标库可能少于源库原始行数。 冻结数据按 24 小时字段展开目标库可能多于源库行数。 告警按事件明细拆分数量可能多于源库告警行。 页面可能按设备聚合少于数据库明细数量。 WalkBy 可能过滤无效关系少于源库历史关系。这些都要写在验收说明里。否则每次验收都会重新解释一遍。总结生产迁移交付的不只是代码。至少应该一起交付迁移代码 dry-run 统计口径 validate 校验口径 人工验收 SQL 异常解释口径 补偿接口验收 SQL只要验收 SQL 和代码口径一致数量对比就会清晰很多。迁移验收最怕的不是数据有差异而是没人能解释差异。