问题背景

迁移验收时，业务经常会打开老系统界面看数量，然后和新系统或数据库统计对比。

常见疑问是：

老系统界面只有 26 条，为什么数据库查出来不止 26 条？
源库有 1000 条，为什么目标库只有 990 条？
告警源库有几百条，老系统界面只显示几条？

这些不一定是迁移错误，很可能是统计口径不同。

老系统界面不是原始明细

很多老系统界面为了展示方便，会做聚合或过滤。

例如告警界面可能按设备聚合：

一个设备多条告警
界面只显示一行
点击详情才看到多条历史告警

此时界面行数和数据库告警明细数一定不一致。

冻结数据的特殊性

冻结数据常见结构是：

一行日期
24 个小时字段

例如：

hour0
hour1
...
hour23

迁移到新系统时，可能会展开成小时级明细。

因此冻结数量不能简单按源库行数统计，而要看：

源库行数 × 每行有效小时字段数

如果一行 24 个小时都有值，最大可以展开成 24 条。

如果某些小时为空，就只展开有值的小时。

实时数据为什么会去重

老系统历史表可能存在重复入库。

例如同一块表、同一上告时间、同一冻结时间，可能出现多条记录。

目标库为了幂等，通常会按唯一键写入：

device_id + recv_time + frozen_time

这样重复数据会被合并。

所以目标库数量少于源库明细数，不一定是漏迁，而可能是合理去重。

如何解释给业务

可以这样解释：

老系统界面展示的是业务视图，数据库保存的是历史明细。
迁移校验以数据库明细和明确唯一键口径为准。
如果源库存在重复数据，新系统会按唯一键幂等合并。
只要缺失校验为 0，数量少一些是合理的。

如何用 SQL 验证

实时数据可以按时间分布查：

select
  date(data_time) as data_day,
  count(*) as row_count
from t_realtimedata
where meter_id in (
  select meter_code
  from as_meter
  where dept_code = '目标部门编码'
)
group by date(data_time)
order by data_day;

冻结数据可以按有效小时统计，示意：

select
  count(*) as source_rows,
  sum(
    (hour0 is not null) +
    (hour1 is not null) +
    (hour2 is not null) +
    (hour3 is not null) +
    (hour4 is not null) +
    (hour5 is not null) +
    (hour6 is not null) +
    (hour7 is not null) +
    (hour8 is not null) +
    (hour9 is not null) +
    (hour10 is not null) +
    (hour11 is not null) +
    (hour12 is not null) +
    (hour13 is not null) +
    (hour14 is not null) +
    (hour15 is not null) +
    (hour16 is not null) +
    (hour17 is not null) +
    (hour18 is not null) +
    (hour19 is not null) +
    (hour20 is not null) +
    (hour21 is not null) +
    (hour22 is not null) +
    (hour23 is not null)
  ) as effective_hour_count
from t_realtimedata
where meter_id in (
  select meter_code
  from as_meter
  where dept_code = '目标部门编码'
);

实际字段名要按项目表结构替换。

告警数量怎么解释

告警界面可能按设备聚合，但迁移是迁告警明细。

可以向业务说明：

界面第一层显示设备列表。
每个设备点详情后才是告警明细。
迁移校验统计的是告警明细数量。

WalkBy 数量怎么解释

WalkBy 也存在类似情况。

源库可能有历史重复任务、无记录任务、跨范围记录。

迁移时以目标表具范围和有效业务关系为准，而不是把所有历史脏关系都照搬。

总结

迁移数量对不上时，不要急着判断漏迁。

先确认口径：

界面是明细还是聚合？
数据库是行数还是展开后数量？
目标库是否做了唯一键去重？
是否过滤了无效历史数据？

迁移验收最重要的是用统一口径对比，而不是用界面行数直接对数据库明细。