WalkBy 迁移为什么复杂

主档迁移通常比较直观：一块表对应一个设备。

WalkBy 抄表业务不一样。它至少涉及：

• 抄表计划
• 抄表册
• 抄表任务
• 当前抄表记录
• 历史抄表记录
• 发布记录
• 计划和册子的关系
• 任务和册子的关系
• 发布记录和历史记录的关系
• 册子和区域的关系

任何一张表没迁完整，都可能导致新系统页面打不开、任务看不到、发布记录断链。

典型表关系

可以用下面这张关系图理解：

rm_plan -> rm_rela_book_plan -> rm_book -> rm_rela_task_book -> rm_task -> rm_record rm_record_hi -> rm_rela_pub_record -> rm_pub_record rm_book -> rm_rela_book_region

其中：

• rm_plan是抄表计划
• rm_book是抄表册
• rm_task是某次实际抄表任务
• rm_record是当前任务下的抄表记录
• rm_record_hi是历史抄表记录
• rm_pub_record是发布批次
• rm_rela_*是业务关系表

迁移边界怎么定

迁移时不能简单按dept_code把所有表都搬过来。

更稳妥的边界是：

以客户表具范围为核心 只迁与这些表具抄表记录相关的任务、册子、计划和发布记录

也就是说，任务是否迁移，不只看任务表本身，还要看它下面有没有目标表具的rm_record。

为什么只迁有 record 的 task

正常业务逻辑下，生成抄表任务时会生成对应的抄表记录。

如果一个任务没有任何相关rm_record，通常说明：

• 历史残留
• 被中途删除过
• 生成失败
• 数据被人工改过
• 与当前迁移范围无关

这类任务迁过去，反而可能造成新系统里出现没有意义的空任务。

所以更合理的策略是：

只迁移存在目标表具抄表记录的任务

为什么源库任务数可能比目标库多

迁移验证时，常见现象是：

源库按简单 SQL 查出 21 个任务 目标库迁移后只有 16 个任务

这时不能马上判断漏迁。

要进一步按业务唯一维度分析，例如：

计划 + 执行人 + 抄表方式 + 任务日期

如果同一天、同计划、同执行人出现多个任务，而业务上只应该有一个，就可能是历史重复任务。

目标库按唯一键幂等合并后，数量少一些是合理的。

如何向业务解释

可以这样解释：

迁移不是机械搬所有历史脏数据，而是按照正常业务可使用的数据结构迁移。 正常生成任务会生成对应抄表记录。 没有记录的任务、重复任务、跨范围关系，属于历史脏数据或无效数据。 目标系统保留可使用的任务和记录，避免把脏关系带入新系统。

如何证明重复任务

可以用类似 SQL 找出重复任务：

selectt.rm_plan_id,t.oper_id,t.rm_type_code,t.task_begin_date,count(distinctt.task_id)astask_count,group_concat(distinctt.task_idorderbyt.task_id)astask_ids,count(r.rm_record_id)asrecord_countfromrm_task tjoinrm_record ronr.task_id=t.task_idjoinas_meter monm.meter_code=r.meter_codewherem.dept_code='目标部门编码'andm.rm_type_codein('01','03')andr.rm_type_codein('01','03')groupbyt.rm_plan_id,t.oper_id,t.rm_type_code,t.task_begin_datehavingcount(distinctt.task_id)>1orderbyt.task_begin_date;

这个 SQL 的目的不是迁移，而是给业务解释：

同一业务维度下确实存在多个历史任务。

发布记录为什么也会不一致

发布记录也可能存在类似情况。

源库的发布记录可能按操作批次存了多条，但真正和目标表具历史抄表记录有关的只有一部分。

迁移时应该以rm_record_hi和rm_rela_pub_record的关系为准，只迁能关联到目标历史记录的发布记录。

总结

WalkBy 迁移最重要的不是“把所有表 count 对齐”，而是保证业务链路可用：

计划能看到 册子能看到 任务能看到 记录能打开 历史能追溯 发布记录不断链 区域能补偿

历史脏数据不应该原样带入新系统。迁移的目标是保留可解释、可使用、可验收的数据结构。