SQL报表聚合时中间结果过大怎么办？用分阶段统计优化性能

在报表系统里，我们常常需要对千万级甚至亿级明细数据做多维度聚合。如果一条SQL直接对原始表进行多层GROUP BY，数据库要先生成庞大的中间结果，再在此基础上汇总，很容易把临时空间撑爆，或者让查询拖到几十秒以上。分阶段统计就是把大聚合拆成两步或多步，先缩小数据规模，再完成最终统计。

为什么中间结果会过大

常见原因有三类：

• 明细表本身字段多、行数大，聚合前无法有效过滤
• 分组维度组合过多，例如按天、地区、渠道、商品同时GROUP BY
• 先JOIN多张表再聚合，笛卡尔式膨胀发生在聚合之前

分阶段统计的基本思路

核心做法是先产出“粗粒度中间表”，再基于中间表做“细粒度报表”。下面用MySQL风格举例，统计某平台每日各渠道的成交额与订单数，但原始表有数十亿行。

第一步：按日与渠道预聚合

把最重的聚合提前，只保留报表必需维度：

-- 创建中间表存放每日渠道汇总
CREATE TABLE tmp_daily_channel_stat (
  stat_date DATE,
  channel_id INT,
  order_cnt INT,
  pay_amount DECIMAL(18,2)
);

-- 从明细表预聚合，只扫描一次原始大表
INSERT INTO tmp_daily_channel_stat
SELECT
  DATE(create_time) AS stat_date,
  channel_id,
  COUNT(*) AS order_cnt,
  SUM(pay_amount) AS pay_amount
FROM order_detail
WHERE create_time >= '2023-01-01'
  AND create_time < '2023-04-01'
GROUP BY DATE(create_time), channel_id;

第二步：基于中间表做报表查询

此时数据量可能已从十亿行降到几万行，再按周或按月汇总就很快：

-- 基于中间表统计每月各渠道表现
SELECT
  DATE_FORMAT(stat_date, '%Y-%m') AS month,
  channel_id,
  SUM(order_cnt) AS month_order_cnt,
  SUM(pay_amount) AS month_pay_amount
FROM tmp_daily_channel_stat
GROUP BY DATE_FORMAT(stat_date, '%Y-%m'), channel_id
ORDER BY month, channel_id;

用子查询代替临时表

如果不想显式建表，也可用派生表把阶段封装在一个语句内，逻辑等价但更易随SQL下发：

SELECT
  month,
  channel_id,
  SUM(order_cnt) AS month_order_cnt,
  SUM(pay_amount) AS month_pay_amount
FROM (
  SELECT
    DATE_FORMAT(create_time, '%Y-%m') AS month,
    channel_id,
    COUNT(*) AS order_cnt,
    SUM(pay_amount) AS pay_amount
  FROM order_detail
  WHERE create_time >= '2023-01-01'
    AND create_time < '2023-04-01'
  GROUP BY DATE_FORMAT(create_time, '%Y-%m'), channel_id
) AS mid
GROUP BY month, channel_id;

注意事项

通过分阶段统计，我们把不可控的大中间结果拆成了可控的小步骤，既降低数据库压力，也方便定位慢点。实际项目中，结合业务特点选择切分维度，往往能让报表查询从超时变为秒回。

SQL报表聚合分阶段统计修改时间：2026-07-29 10:12:22