group by cube 并不天然更高效，而是穷举所有2ⁿ种组合，导致扫描次数多、资源开销大；rollup则逐层上卷、可复用中间结果，通常更优。
GROUP BY CUBE 在 SQL Server 中并不天然更高效——它只是更“完整”，而完整性是以计算和存储开销为代价换来的。是否“高效”，完全取决于你的分析目标是否真需要全部 2ⁿ 种组合。
GROUP BY CUBE 的实际执行逻辑是穷举，不是优化
SQL Server 对 CUBE 的实现是生成所有维度组合的独立分组子计划，再合并结果。它不复用中间聚合结果，比如对 CUBE(a, b, c)：
- 先扫一遍数据算
GROUP BY a, b, c - 再扫一遍算
GROUP BY a, b - 再扫一遍算
GROUP BY a, c - ……直到
GROUP BY ()（全表聚合）
ROLLUP(a, b, c) 则不同：它按顺序逐层上卷，可复用前缀聚合（如先算 a,b,c，再基于该结果合并出 a,b 和 a），物理扫描次数通常更少。
常见错误现象：
- 同样三列维度，
CUBE查询比ROLLUP慢 2–5 倍，且内存/TempDB 压力明显升高 - 执行计划里出现多个 Hash Match Aggregate 或多个 Table Spool，说明重复扫描或缓存膨胀
什么时候 CUBE 反而“省事”？看场景
CUBE 的价值不在性能，而在免去手工拼 UNION ALL 或写物化视图的维护成本，适合以下情况：
- 报表模板固定、维度 ≤ 3 且基数低（如
region只有 5 值、product_category只有 8 值） - 用户需要任意切片下钻（比如前端支持拖拽任意字段组合查看小计），且无法预判组合路径
- 数据量小（INDEX IX_cube ON t(a,b,c) INCLUDE (sales)）
不推荐的场景：
- 维度列含高基数字段（如
user_id、order_date） - 实时 OLTP 查询中嵌入
CUBE - 仅需部分组合（比如只要
(a,b)、(a)、()），却写了CUBE(a,b,c)
GROUPING() 是必须配套的判断工具，否则 NULL 会误导
CUBE 输出中，NULL 不代表原始数据为空，而是“该维度未参与本次分组”。直接 ISNULL(col, 'ALL') 显示可能混淆语义。
正确做法是用 GROUPING(col) 判断：
-
GROUPING(region) = 1→ 这行是 region 被“立方忽略”的汇总行 -
GROUPING(region) = 0→ region 是真实值
示例：
SELECT CASE WHEN GROUPING(region) = 1 THEN 'ALL_REGION' ELSE region END AS region, CASE WHEN GROUPING(product) = 1 THEN 'ALL_PRODUCT' ELSE product END AS product, SUM(sales) AS total FROM sales_data GROUP BY CUBE(region, product);
漏掉 GROUPING() 就容易把 (NULL, 'Laptop') 误读成“region 缺失的 Laptop 销售”，实际是“所有 region 的 Laptop 小计”。
真正影响效率的从来不是 CUBE 关键字本身，而是你让数据库为多少种组合付出代价。4 列就 16 种，5 列就 32 种——每多一列，理论行数翻倍，而 NULL 填充、临时空间、网络传输都跟着涨。上线前不看 STATISTICS IO 和执行计划里的 Actual Number of Rows，很容易在高峰期被反向教育。
