SQL复杂报表聚合慢的核心在于实时计算明细数据，应通过分层统计、预计算、冷热分离和轻量缓存重构链路：明细→日/月汇总→报表层；物化视图或调度预聚合；按时间分区与冷数据归档；Redis缓存T+1结果。
SQL复杂报表聚合慢，核心问题常出在实时计算大量明细数据上。分层统计与预计算不是“加索引”或“调优SQL”能解决的，而是重构数据加工链路：把耗时的聚合操作从查询时移到写入或调度时，用空间换时间。
分层统计：按业务粒度逐级汇总
避免一张大宽表全量聚合，把统计口径拆成“明细层 → 日粒度汇总层 → 周/月汇总层 → 主题宽表层”。比如销售报表：
- 明细层：订单表（每单一条，含商品、时间、金额、渠道等）
- 日汇总层：按日期+渠道+品类聚合订单数、GMV、UV，每天凌晨跑一次
- 月汇总层：基于日汇总表再聚合，不碰原始订单
- 报表层：直接查月汇总表或缓存结果，响应从分钟级降到毫秒级
预计算：物化中间结果，支持灵活下钻
对高频、固定维度组合（如“地区 × 时间 × 销售类型”），提前生成物化视图或汇总表。关键点：
- 用数据库原生物化视图（如 PostgreSQL 的 MATERIALIZED VIEW，Oracle 的物化视图，或 ClickHouse 的 MATERIALIZED VIEW 引擎）自动刷新
- 若数据库不支持，用调度任务（Airflow/DolphinScheduler）定时执行 INSERT INTO ... SELECT ... 写入汇总表
- 给汇总表建好复合索引，例如 (dt, region, biz_type)，确保下钻查询走索引
冷热分离 + 分区裁剪，减少扫描量
即使做了预计算，历史数据仍可能拖慢查询。需配合存储策略：
- 按时间分区（如按天/月分区），查询指定时间段时只加载对应分区
- 将 1 年前的冷数据归档到低成本存储（如 Hive 表或对象存储），报表默认只查热区
- 在汇总表中保留“累计值”字段（如截至当日的总销售额），避免跨月 SUM 聚合
轻量级缓存兜底，应对突发查询高峰
对 T+1 更新、维度固定的报表（如首页经营看板），可加一层应用缓存：
- 汇总结果生成后，写入 Redis，Key 设计为 report:sales:202405
- 接口先查缓存，未命中再查库并回填，设置合理过期时间（如 1 小时）
- 缓存内容结构化（JSON 或 Hash），支持按子维度快速提取，不依赖 SQL 查询
分层统计和预计算不是银弹，但能系统性压降报表延迟。关键是根据业务更新频率、查询模式、资源成本做取舍：T+1 报表适合离线预计算，实时看板则需结合流式聚合（如 Flink）补足。
