sql报表多维度聚合慢的核心原因是实时扫描分组计算，解决方法是构建预计算立方体（cube），即按时间、地区、品类等维度预先汇总指标存入olap存储，查询时直接读取。
SQL报表多维度聚合慢，核心原因是每次查询都要实时扫描、分组、计算，数据量一大，性能就明显下降。解决思路不是优化单条SQL，而是提前把常见聚合结果算好存起来——也就是构建“立方体”（Cube），实现预计算。
什么是立方体预计算
立方体是多维数据模型中的概念，把业务指标（如销售额）按多个维度（如时间、地区、产品类别、渠道）预先汇总成各种组合粒度的结果。例如：
- 年+省+一级类目 → 总销售额
- 月+城市+二级类目 → 平均客单价
- 日+门店+SKU → 销量总和
这些结果在ETL或定时任务中提前算出，存入宽表或专用OLAP存储（如Doris、ClickHouse、StarRocks），查询时直接取数，毫秒级响应。
哪些场景适合建立方体
不是所有报表都值得做预计算。重点关注以下几类：
- 查询频率高、模式固定（比如每天看的销售日报、周同比分析）
- 维度组合明确且数量可控（一般不超过5～6个常用维度）
- 数据更新不频繁（T+1或小时级更新即可，实时性要求不高）
- 明细数据量大（亿级以上），实时GROUP BY已明显卡顿
怎么低成本落地立方体
不必一开始就上重型OLAP引擎。可分三步渐进实施：
- 第一阶段：用现有数仓（如Hive/Spark SQL）跑定时任务，按常用维度组合生成汇总表，加分区和索引，供BI工具直连
- 第二阶段：引入物化视图（如ClickHouse的ReplacingMergeTree + 物化视图，或PostgreSQL 12+的物化视图），自动维护预聚合结果
- 第三阶段：接入Cube引擎（如Apache Druid、Doris Rollup表、Kylin），支持更灵活的维度下钻与自动路由
避免踩坑的关键细节
预计算不是“一建了之”，要注意几个实际问题：
- 维度基数太高（如用户ID、订单号）不能直接入Cube，需聚合或脱敏后再参与分组
- 增量更新要设计好merge逻辑，避免全量重刷；建议按时间分区滚动刷新
- 给Cube加清晰的命名和元数据说明（比如sales_cube_monthly_province_category），方便下游识别和复用
- 保留1～2张关键明细表作兜底，当用户临时要查未预计算的维度组合时可快速响应
