LabelChange-server/.trae/documents/fix_24h_rate_over_100_percent_plan.md

24H换单率超过100%的问题诊断与修复计划

问题描述: 24小时换单率特别高，超过100%，有的甚至达到899%

根本原因分析（需要验证）:

可能的原因

原因1：分母计算错误 - 高标签率应该换单数重复计算

当前逻辑：

24H换单率 = 高标签率考核通过数 / 高标签率应该换单数

问题：高标签率应该换单数可能被重复计算
- DailyHighLabelRateShould 可能统计了相同日期的多个记录
- 或者在JOIN时产生了重复

原因2：分子计算错误 - 高标签率考核通过数重复

可能的重复来源：

• DailyBeforeNoonPassed 和 DailyAfternoonPassed 可能有重叠统计
• 同一个包裹被计算了多次
• 或者考核通过数的汇总逻辑有问题

原因3：JOIN逻辑问题

LEFT JOIN 导致的重复：

LEFT JOIN DailyHighLabelRateShould dhlrs ON t.日期 = dhlrs.日期
LEFT JOIN DailyHighLabelRateAssessed dhras ON t.日期 = dhras.日期

• 可能导致同一日期的数据被复制
• 特别是在有多条记录的情况下

原因4：GROUP BY缺失

DailyHighLabelRateShould/DailyLowLabelRateShould中的GROUP BY问题：

• 这些CTE中可能没有正确按日期分组
• 导致统计重复

诊断步骤

步骤1：检查DailyHighLabelRateShould的逻辑

需要验证：
1. 是否正确统计了冻结标签率>=80%的交接单
2. 按照到货时间分组是否正确
3. 是否存在DISTINCT或重复计算
4. 一个交接单是否被计算多次

步骤2：检查DailyHighLabelRateAssessed的逻辑

需要验证：
1. 是否正确汇总了16点前+16点后的考核通过
2. UNION ALL 是否导致了重复
3. GROUP BY 日期后是否还有重复

步骤3：检查数据表中的问题

需要验证：
1. DailyBase 中是否有重复的到货记录
2. DailyBeforeNoonPassed 中是否有重复统计
3. DailyAfternoonPassed 中是否有重复统计
4. 同一个订单是否被计算多次

步骤4：检查JOIN的重复问题

需要验证：
1. DailyStatsWithPrev 的数据是否重复
2. 各个 LEFT JOIN 是否产生了笛卡尔积
3. 是否需要使用 DISTINCT 或 GROUP BY

修复方案（待确定）

方案A：修复DailyHighLabelRateShould

检查点：

• 验证 COUNT(DISTINCT ar.NeutralWaybillNumber) 是否正确
• 检查 GROUP BY DATE(CONVERT_TZ(ar.到货时间, '+00:00', '-05:00')) 是否缺失某些字段
• 验证 INNER JOIN 条件是否正确
• 确保每个到货日期只有一条记录

修复方式：

• 可能需要加上 DISTINCT 或改进 GROUP BY
• 确保同一日期的高标签率应该换单数只被计算一次

方案B：修复DailyHighLabelRateAssessed

检查点：

• UNION ALL 中两个SELECT是否产生了重复
• GROUP BY 日期后的结果是否已去重
• 是否需要改为 UNION（去重）

修复方式：

• 检查子查询逻辑是否正确
• 如果两个SELECT有重叠，需要改为 UNION DISTINCT

方案C：修复主SELECT的JOIN

检查点：

• 是否产生了笛卡尔积
• 多个 LEFT JOIN 是否导致了行数增加
• 是否需要添加 GROUP BY 来聚合重复的行

修复方式：

• 检查是否所有JOIN的ON条件都是单一条件
• 考虑是否需要在外层SELECT中加GROUP BY
• 或者在各个CTE中更早地进行聚合

实施步骤

第1阶段：问题定位

1. 运行诊断查询

   • 检查 DailyHighLabelRateShould 的输出（每日记录数）
   • 检查 DailyHighLabelRateAssessed 的输出（每日记录数）
   • 检查 DailyBeforeNoonPassed 和 DailyAfternoonPassed 的输出
   • 对比 DailyBase 中的记录数

2. 对比数据

   • 高标签率应该换单数是否超过了实际的订单数
   • 高标签率考核通过数是否超过了应该换单数
   • 查找异常倍数关系（899% = 大约9倍，可能表示9倍重复）

3. 追踪单个日期

   • 选择某一天的数据进行详细追踪
   • 逐个CTE验证数据流向

第2阶段：修复问题

根据诊断结果，选择对应的修复方案：

1. 如果是DailyHighLabelRateShould问题

   • 修改CTE逻辑
   • 验证修复后的输出

2. 如果是DailyHighLabelRateAssessed问题

   • 修改UNION ALL逻辑或GROUP BY
   • 验证修复后的输出

3. 如果是JOIN问题

   • 在主SELECT中添加GROUP BY
   • 或改进各CTE的聚合逻辑

4. 如果是数据源问题

   • 检查DailyBeforeNoonPassed是否有重复
   • 检查DailyBase是否有重复
   • 修复源头CTE

第3阶段：验证修复

1. 运行修复后的查询

   • 24H换单率应该 <= 100%
   • 高标签率应该换单数应该 = DailyBase中满足条件的记录总数
   • 高标签率考核通过数应该 <= 高标签率应该换单数

2. 逻辑检查

   • 高标签率考核通过数 / 高标签率应该换单数 = 24H换单率
   • 验证计算公式的准确性

3. 对比测试

   • 用简单的示例数据验证逻辑
   • 手工计算一个日期的结果，对比SQL输出

关键检查清单

• 是否存在 COUNT(*) 而不是 COUNT(DISTINCT)?
• 是否有 INNER JOIN 导致的重复？
• 是否有 LEFT JOIN 没有正确的聚合？
• GROUP BY 中是否遗漏了某些字段？
• UNION ALL 是否应该用 UNION？
• 是否有子查询在没有 GROUP BY 的情况下返回多行？
• 是否同一交接单/包裹被多个日期统计了？

预期结果

修复后：

• 24H换单率 <= 100%
• 分子 <= 分母
• 各项指标 >= 0
• 计算过程可追踪和验证