sql 多维统计慢的核心原因是实时聚合明细表，解决关键是预聚合 + 数据立方体：预聚合提前计算常用分组指标存入汇总表；cube 则结构化存储多维度组合聚合结果，支持毫秒级切片钻取。
SQL 多维统计慢，核心原因往往是每次查询都在原始明细表上实时聚合，数据量大、维度组合多时，扫描行数和计算开销剧增。解决的关键不是优化单条 SQL，而是改变计算模式——把“查时算”变成“算好再查”，即通过预聚合 + 数据立方体（Cube）提前物化常用聚合结果。
什么是预聚合？
预聚合指在数据写入或定时任务中，预先按常见分组（如日期、地区、品类、渠道等）计算好 SUM、COUNT、AVG 等指标，并将结果存入单独的汇总表。查询时直接读取汇总表，跳过对明细表的扫描和聚合计算。
例如：一张日志表每天千万级记录，常查“各城市每日订单金额”，可建一张 city_day_agg 表，字段为city, day, order_amt_sum, order_cnt，每日凌晨跑一次 INSERT …… SELECT 聚合入库。
- 适用场景：维度固定、查询模式稳定、时效性要求不高（T+ 1 可接受）
- 关键点：聚合粒度要覆盖高频查询的最小组合，避免过度细分导致汇总表膨胀
- 注意：需配套维护机制，防止明细更新后汇总数据不一致（如退款未回刷）
数据立方体（OLAP Cube）怎么用？
数据立方体是预聚合的结构化升级：它把所有有意义的维度组合（如 [日期]、[日期 + 城市]、[日期 + 品类]、[日期 + 城市 + 品类] 等）对应的聚合结果，统一建模、分层存储。查询任意切片（slice）、切块（dice）或钻取（drill-down），都能命中已预计算的层级，响应毫秒级。
工具层面，可用 Apache Kylin、Doris（支持 Rollup 表）、ClickHouse（物化视图 +ReplacingMergeTree）、或者 StarRocks（Aggregate Model）来构建 Cube。以 Doris 为例，建表时指定 AGGREGATE KEY(city, dt) 并定义SUM(order_amt)，系统自动维护该粒度的聚合值。
- 优势：一套模型支撑多种维度组合查询，无需为每种 GROUP BY 单独建汇总表
- 代价：存储放大（不同组合都存一份）、构建延迟（Cube 刷新需要时间）
- 建议：从核心 2–3 个高基数维度出发建基础 Cube，再按需扩展，避免“全组合爆炸”
预聚合与 Cube 如何配合现有架构？
不必推翻重来。可在离线数仓（如 Hive/Spark）中构建 T + 1 预聚合表供报表使用；在实时数仓（如 Flink + Doris/StarRocks）中构建分钟级 Cube 支撑 BI 自助分析；明细层保留原始数据，用于少数需要下钻明细的场景。
- 查询路由策略：BI 工具或中间服务识别 SQL 中的 GROUP BY 字段，自动路由到对应粒度的预聚合表或 Cube，对用户透明
- 冷热分离：高频维度组合走 Cube，低频或临时分析仍走明细表 + 资源队列限流
- 监控重点：汇总表数据延迟、Cube 构建成功率、查询命中预聚合的比例（可通过执行计划或代理层日志统计）
什么情况不适合预聚合？
不是所有多维统计都适合预计算。以下场景需谨慎：
- 维度值动态变化极多（如用户自定义标签、长尾 SKU），导致 Cube 组合爆炸或预聚合表过大
- 查询条件高度随机（WHERE 条件千变万化，且无法归类为固定维度组合）
- 业务要求亚秒级实时性（如风控场景），而 Cube 刷新做不到毫秒级
- 数据量本身不大（百万级以内），优化索引 + 分区可能比建 Cube 更轻量
此时可转向向量化执行引擎（如 ClickHouse）、列存压缩、物化视图自动推荐（如 PostgreSQL 16+）、或结合缓存（Redis 聚合结果）做折中。
