数据异常排查报告

报告时间： 2026-03-09
涉及系统： REPORT.REPORT_2026CELUE_Day（策略日报落地表）
涉及存储过程： P_REPORT_2026CELUE_DAY、P_REPORT_ALL_FCDFLX_M

---

一、问题描述

在对策略日报落地表（REPORT_2026CELUE_Day）与直连查询结果进行比对时，发现两个来源的 order_succ（订购成功数，以下简称 DG）存在差异：

日期	落地表 DG	直连查询 DG	差值
20260301	5	5	0 ✅
20260302	9	9	0 ✅
20260303	39	45	-6 ❌
20260304	35	65	-30 ❌
20260305	54	54	0 ✅
20260306	27	27	0 ✅
20260307	25	25	0 ✅
20260308	22	22	0 ✅

3月3日和4日的落地表数据比直连查询分别少 6 和 30。

---

二、排查过程

第一步：确认直连查询本身的正确性

首先对直连查询的 JOIN 逻辑进行验证。初始版本使用了 OR 条件关联马标表：

JOIN T_2026CELUE_MABIAO tm 
  ON tr.celue_id = tm.celue_id 
  OR tr.celue_id = tm.celue_id_new

发现问题：OR JOIN 在马标表存在一条记录同时拥有 celue_id 和 celue_id_new 的情况下，会导致日报中一条记录匹配马标表多行，SUM(order_succ) 被重复累加，结果虚高。

修复直连查询：将 OR JOIN 改为 UNION 子查询，消除重复匹配：

JOIN (
    SELECT celue_id AS join_key, dinggou_type 
    FROM T_2026CELUE_MABIAO WHERE celue_id IS NOT NULL
    UNION
    SELECT celue_id_new, dinggou_type 
    FROM T_2026CELUE_MABIAO WHERE celue_id_new IS NOT NULL
) tm ON tr.celue_id = tm.join_key

修复后重新比对，3、4号的差值仍然存在，直连查询的数字依然偏大，说明差值不是直连查询的问题，而是落地表数据缺失。

---

第二步：定位落地表缺失的具体策略

对比3号和4号两天在落地表和直连查询中各自的非零策略，发现直连查询中存在落地表没有的策略 ID：

3号（差6）直连查询独有：

celue_id	order_succ
2227954	4
2227974	1
2227983	1

4号（差30）直连查询独有：

celue_id	order_succ
2227954	12
2227983	6
2228515	10
2228563	2

差值数字完全吻合：3号 4+1+1=6，4号 12+6+10+2=30。

---

第三步：查找这些策略在马标表中的状态

查询马标表确认这几个 celue_id 的注册情况：

SELECT celue_id, celue_id_new, dinggou_type, create_time
FROM REPORT.T_2026CELUE_MABIAO
WHERE celue_id_new IN ('2228515','2228563','2227954','2227974','2227983');

结果：

celue_id（旧）	celue_id_new（新）	dinggou_type	create_time
,2100307,2165937,2175533,	2228515	指令订购	2026-03-05 16:14:29
,2100334,2165940,2175531,	2228563	指令订购	2026-03-05 16:14:29
,2112145,2147408,2165950,	2227954	指令订购	2026-03-05 16:14:29
,2165955,	2227974	指令订购	2026-03-05 16:14:29
,2165959,	2227983	指令订购	2026-03-05 16:14:29

5条记录的 create_time 全部是 2026-03-05 16:14:29，即3月5日下午才新增入马标表。

---

第四步：确认落地表数据的写入时间

查询落地表中3号和4号数据的实际写入时间：

SELECT MIN(load_time), MAX(load_time)
FROM REPORT.REPORT_2026CELUE_Day
WHERE zhangqi IN ('20260303', '20260304');

结果：

MIN(LOAD_TIME)	MAX(LOAD_TIME)
2026-03-04 09:34:47	2026-03-05 09:45:06

---

第五步：还原完整时序，确认根因

2026-03-04 09:34  存储过程写入3号数据  ─┐
2026-03-05 09:45  存储过程写入4号数据  ─┤  马标表此时无新策略
                                        │  g（日期网格）不含 2227954 等 5 个 celue_id
                                        │  日报数据 LEFT JOIN 后补零，order_succ = 0
2026-03-05 16:14  马标表新增5个策略    ─┘
2026-03-05 后     直连查询实时读马标表，能匹配到新策略，sum 正确
落地表3、4号      已落表未重跑，新策略数据缺失，DG 偏少

---

三、根因总结

存储过程的策略清单（g，日期网格）是在每次执行时从马标表实时生成的。 3号和4号数据写入时，马标表尚未录入 5 个新的指令订购策略，导致这些策略的 celue_id 未进入日期网格，日报数据在 LEFT JOIN 后全部被 NVL 补零，最终落地表中这 5 个策略的 DG 均为 0，而非真实值。

直连查询无此问题，因为它在查询执行时实时读取马标表当前状态，新策略已经存在，可以正常匹配。

---

四、解决方案

立即修复

马标表在3月5日新增策略后，需从3月1日起重跑存储过程，使新策略的历史数据全部补入落地表：

EXEC P_REPORT_2026CELUE_DAY('20260301', '20260308');

重跑时存储过程会用当前马标表重新构建日期网格，5个新策略的 celue_id 将进入 g，历史日报数据可正常 JOIN，3号4号的差值消失。

长期机制建议

场景	建议操作
马标表新增策略	从该策略有日报数据的最早日期起重跑存储过程
马标表修改 celue_id_new	同上，需重跑受影响日期段
日常监控	定期对比落地表与直连查询，发现差值及时排查

---

五、附：本次涉及的其他问题记录

5.1 P_REPORT_ALL_FCDFLX_M — 短信内嵌H5渠道分类错误

问题：chl_flag=22（短信内嵌H5页面）的日订购数从 0206 起持续偏高。

根因：llbxsbggw1（流量包-小时包广告位1）、llbxsbggw2（流量包-小时包广告位2）等手厅APP渠道从0206起开始产生订单，但未在存储过程 CASE 条件中覆盖，掉入 else 22 兜底，被错误归入短信内嵌H5，导致该渠道数据虚高。

后续持续发现 qykpggw1、stjfyzxys、stscyl、stwdxxyxw、llbxsbggw3 等同类手厅APP渠道相继出现，均为同一问题。

修复：在存储过程 SELECT 和 GROUP BY 的 CASE 语句中，在 else 22 前补充整类判断：

when b.CHL_FLAG_DESC = '中国联通app' then 2  -- 手厅APP渠道整类兜底

注意：SELECT 和 GROUP BY 两处 CASE 必须完全一致，否则 Oracle 会产生错误分组。

受影响范围：20260206 至今，需重跑：

EXEC P_REPORT_ALL_FCDFLX_M('20260206', '20260228');

---

报告人：aluvfy
最后更新：2026-03-09