上传源代码版本

.trae/documents/SQL查询性能优化方案.md

@@ -0,0 +1,53 @@
+# SQL查询性能优化方案
+## 优化目标
+将`最新运营监控.sql`和`客户维度运营监控.sql`的查询耗时从当前的2分钟降低到30秒以内
+## 性能瓶颈分析
+当前SQL执行慢的主要原因：
+1. **多表关联复杂度高**：存在多次LEFT JOIN、CROSS JOIN，关联数据量较大
+2. **重复扫描同一张表**：多个CTE独立扫描`label_scan_history`、`label_replace_requests`表，重复IO开销大
+3. **子查询效率低**：部分指标使用EXISTS子查询，逐行判断效率低
+4. **索引缺失**：常用关联字段、过滤字段缺少有效索引，查询时全表扫描
+5. **计算逻辑重复**：日期转换、维度判断等逻辑在多处重复计算
+## 优化方案（按优先级排序）
+### 方案一：索引优化（实施成本最低，效果最明显）
+#### 需创建的索引：
+| 表名 | 索引字段 | 用途 |
+|------|----------|------|
+| `label_scan_history` | `NeutralWaybillNumber, CreatedAt, Result, Description` | 覆盖扫描记录的关联、过滤、统计需求，避免回表 |
+| `label_scan_history` | `CreatedAt, Result, NeutralWaybillNumber` | 覆盖独立统计CTE的统计需求，直接从索引获取统计数据 |
+| `label_replace_requests` | `MasterPackageNumber, BillOfLadingNumber, customerid, LabelRetrievedAt` | 覆盖订单表的关联、过滤需求 |
+| `arrival_handover_forms` | `HandoverNumber` | 覆盖交接单匹配关联需求 |
+| `customers` | `Id, CustomerCode` | 覆盖客户维度关联需求 |
+> 所有索引均为组合索引，实现查询全覆盖，避免回表查询
+### 方案二：SQL逻辑优化（无额外开发成本，仅修改SQL结构）
+1. **合并重复CTE**：将多个独立扫描`label_scan_history`的CTE合并为一个，一次性计算所有扫描相关指标（成功数、失败数、STOP数、扫描数），减少表扫描次数
+2. **替换CROSS JOIN**：将`DistinctDates CROSS JOIN OrderFullInfo`改为更高效的关联方式，减少笛卡尔积计算量
+3. **移除不必要的逻辑**：删除冗余的判断条件和重复计算逻辑
+4. **替换EXISTS子查询**：将指标统计中的EXISTS子查询改为预计算的关联方式
+### 方案三：中间汇总表方案（适合准实时场景，性能提升最大）
+创建定时任务（每15分钟/每小时执行一次），预计算以下中间结果：
+1. `daily_scan_stats`：每日扫描统计结果（日期、扫描数、成功数、失败数、STOP数）
+2. `daily_order_stats`：每日订单统计结果（日期、新增换单数、应该换单数、标签推送数等）
+3. `customer_daily_stats`：客户维度每日统计结果
+查询时直接读取预计算的汇总表，查询耗时可降低到秒级
+### 方案四：物化视图方案（适合MySQL 8.0+版本）
+创建物化视图预计算常用的统计维度，自动刷新数据，查询时直接读取物化视图
+## 实施步骤
+### 第一步：先实施索引优化（1小时内完成）
+1. 创建上述所有建议的组合索引
+2. 重新执行SQL测试性能，预计可降低50%以上的耗时
+### 第二步：实施SQL逻辑优化（2小时内完成）
+1. 重构SQL结构，合并重复CTE
+2. 优化关联逻辑和子查询
+3. 测试验证数据准确性和性能提升
+### 第三步：（可选）实施中间汇总表方案（半天内完成）
+1. 设计汇总表结构
+2. 开发定时汇总脚本
+3. 修改查询SQL读取汇总表
+## 预期效果
+- 仅实施索引+SQL逻辑优化：查询耗时可降低到30-60秒
+- 实施中间汇总表方案：查询耗时可降低到1-5秒
+## 验证标准
+1. 查询耗时≤30秒
+2. 统计结果和原SQL完全一致
+3. 无业务逻辑偏差