SQL CUBE本质是GROUP BY列的幂集展开，生成所有子集组合（含空集），并非OLAP多维立方体；它通过UNION ALL合并多个分组结果，无层级、不支持钻取切片，仅为语法糖。
SQL CUBE 生成的不是“多维数据集”，而是分组组合的全集
CUBE 不是 OLAP 多维立方体，它只是对 GROUP BY 列做幂集展开——即所有可能的子集组合（包括空集，对应总计行）。你看到的“多维报告”其实是多个 GROUP BY 子句结果的 UNION ALL 合并，没有层级、没有坐标轴、不支持切片/钻取。别被名字误导，它本质是语法糖。
实操时注意：
- CUBE(a, b, c) 会生成 2³ = 8 组分组：(a,b,c)、(a,b)、(a,c)、(b,c)、(a)、(b)、(c)、()；
- 空括号 () 对应全表聚合，NULL 值在该行所有分组列中出现，代表“全部”；
- 某些数据库（如 MySQL 8.0+）需开启 sql_mode 中的 ONLY_FULL_GROUP_BY 兼容模式，否则报错；
- PostgreSQL 和 SQL Server 默认支持，但 PostgreSQL 要求所有非分组列必须用聚合函数包裹，否则直接报错。
怎么写才不出错：CUBE 的列顺序和 NULL 含义必须对齐
CUBE 输出里，每个分组组合的 NULL 出现在哪一列，取决于你在 CUBE() 中写的列顺序。比如 CUBE(region, product) 中，第一列为 region，第二列为 product；当某行 region 是 NULL、product 是 'Laptop'，表示“所有地区的 Laptop 总和”；而 region = 'US'、product = NULL 表示“US 地区所有产品总和”。
常见踩坑点：
- 把 CUBE(a,b) 和 CUBE(b,a) 当作等价——它们输出行数相同，但 NULL 分布位置不同，排序后看起来完全不一样；
- 在 ORDER BY 里直接按原列名排序，导致 NULL 被排到最前或最后，掩盖逻辑分组结构；建议用 GROUPING() 函数辅助排序：ORDER BY GROUPING(region), region, GROUPING(product), product；
- 忘记用 COALESCE() 或 CASE WHEN GROUPING(...) = 1 THEN 'All' 替换 NULL，报表里直接显示 NULL 容易被业务方质疑数据缺失。
性能很敏感：CUBE 的计算量随维度指数增长
CUBE 的执行计划通常触发完整扫描 + 多轮哈希聚合，时间复杂度接近 O(n × 2^k)，其中 k 是 CUBE 中列数。加 1 列，行数翻倍，内存和临时空间压力陡增。
能优化的点：
- 避免在大宽表上对 4+ 列用 CUBE，优先拆成多个 GROUP BY + UNION ALL；
- 在 MySQL 中，确认是否启用了 optimizer_switch='derived_merge=off'，否则 CUBE 子查询可能被错误重写；
- SQL Server 可以加 OPTION (HASH GROUP) 强制使用哈希聚合，比默认的流聚合更稳；
- 如果只想要部分组合（比如不要“全 NULL”行），别硬套 CUBE，改用 GROUPING SETS((a,b), (a), (b), ()) 显式控制。
替代方案比 CUBE 更可控：ROLLUP 和 GROUPING SETS
多数真实报表场景其实不需要全组合。比如按年→月→日下钻，ROLLUP(year, month, day) 生成的是 (year,month,day)、(year,month)、(year)、() 四层，符合自然层级；而 CUBE 还会额外算出 (month,day)、(month)、(day) 这些无业务意义的组合。
更灵活的做法：
- 用 GROUPING SETS((a,b), (a,c), (b)) 精确指定要哪几组，避免冗余计算；
- 在 Presto/Trino 或 Spark SQL 中，CUBE 可能被下推失败，但 GROUPING SETS 兼容性更好；
- 如果下游是 BI 工具（如 Tableau、Superset），它们内置的多维分析能力已封装好层级与过滤逻辑，直接传明细数据比塞一个 CUBE 结果更利于交互响应。
真正要用 CUBE 的时候很少——通常是临时查口径、验证聚合逻辑、或者 legacy 报表迁移。写之前先问自己：这些组合真的都要？有没有更轻量的表达方式？
