SQL报表周报统计慢的核心原因是数据量大、聚合维度多、全表扫描频繁；解决方案是分批聚合，即先按天预聚合存入summary_daily表，再按周汇总，或用递归CTE模拟分批处理。
SQL报表周报统计慢，核心问题往往不是单条SQL写得不好，而是数据量大、聚合维度多、全表扫描频繁，尤其在按周汇总订单、日志、行为等明细表时，直接GROUP BY加WHERE范围容易触发磁盘临时表、内存溢出或索引失效。
分批聚合的本质是“用空间换时间+控制计算粒度”
不一次性拉取7天全量明细做聚合，而是先按天（或按小时）预聚合关键指标，再合并周粒度结果。这样每批次数据量可控，能走索引、利用物化中间结果、避免长事务锁表。
- 每天凌晨跑一次日聚合：把当日订单数、支付金额、用户数等存入summary_daily表，带日期字段和业务维度（如渠道、地区）
- 周报查询时只JOIN 7张日聚合表（或查summary_daily WHERE date BETWEEN '周一' AND '周日'），再SUM/AVG即可
- 日表本身可建复合索引（date, channel, region），查询速度通常提升5–20倍
用窗口函数+递归CTE实现动态分批（适合不能加汇总表的场景）
若无法修改数据库结构，可在SQL层模拟分批：先按主键或时间ID分段，再逐段聚合后UNION ALL。例如：
示例（PostgreSQL）：
WITH RECURSIVE batch AS (
SELECT min(id) AS start_id, min(id) + 9999 AS end_id FROM orders WHERE create_time >= '2024-06-01'
UNION ALL
SELECT start_id + 10000, end_id + 10000 FROM batch WHERE start_id = '2024-06-01')
)
SELECT sum(amount), count(*) FROM orders o
JOIN batch b ON o.id BETWEEN b.start_id AND b.end_id
WHERE o.create_time >= '2024-06-01' AND o.create_time GROUP BY b.start_id;
配合物化视图或定时任务固化中间结果
对稳定周期性报表，别每次都重算。把“分批聚合”的结果固化下来：
- 用物化视图（如PostgreSQL 9.4+、Oracle MVIEW、MySQL可通过定时EVENT+汇总表模拟）每日刷新一次日汇总
- 周报SQL直接查物化视图，响应从分钟级降到秒级
- 加个简单校验逻辑：比如对比当日明细count(*)与物化视图sum(count)，偏差超1%则告警并触发重刷
注意边界：分批不是万能，要避开这些坑
分批聚合有效，但需警惕几个典型陷阱：
- 时间字段没索引或类型不匹配（如用字符串存时间、WHERE里对create_time用DATE()函数导致索引失效）
- 分批粒度太小（如按每100行分）引发大量小查询，网络和调度开销反超收益
- 未处理跨天/跨月/节假日逻辑（例如周一是5月31日，但业务周从周日开始，需统一周标识字段如YEARWEEK(create_time,1)）
- 忽略NULL值聚合影响（COUNT(*) ≠ COUNT(col)，SUM(col)会跳过NULL，必要时用COALESCE）
