CUBE是SQL标准运算符，需配合GROUP BY使用；其生成全维度组合时用NULL标记汇总行，须借GROUPING函数区分真实NULL与占位NULL，多维场景推荐GROUPING_ID，超4维易因组合爆炸致性能骤降。
CUBE 不是函数，不能“调用”，它是一个 SQL 标准运算符，必须配合 GROUP BY 使用；直接写 SELECT ... GROUP BY CUBE(...) 才能生成全维度组合聚合结果，否则会报错或被忽略。
为什么 CUBE 一用就出 NULL，还分不清是数据本身为空还是汇总行？
这是最常踩的坑：CUBE 会在汇总行中把未参与分组的列置为 NULL，但原始数据里也可能真有 NULL 值。不加区分直接展示，报表就容易误读。
-
GROUPING(region)返回1表示该行是 region 维度被“折叠”产生的汇总（即NULL是占位符），返回0表示正常分组值 - 别用
COALESCE(region, 'ALL')粗暴替换——如果 region 原本就是NULL，会被误标为汇总行 - 推荐写法：
CASE WHEN GROUPING(region) = 1 THEN 'ALL_REGION' ELSE region END - 多个维度时，
GROUPING_ID(region, product, time)可一次性返回位图整数，比嵌套多个GROUPING()更紧凑
GROUP BY CUBE(a,b,c) 和手写 GROUPING SETS 有什么实际差别？
语义等价，但执行路径和可维护性不同。CUBE 是声明式写法，底层仍可能展开为多个分组逻辑；GROUPING SETS 是显式枚举，更可控。
-
CUBE(a,b,c)等价于GROUPING SETS ((a,b,c),(a,b),(a,c),(b,c),(a),(b),(c),())，共 8 种组合 - 如果你只想要其中 5 种（比如不要纯
(b)和(c)的单维汇总），硬用 CUBE 就会多算、多传、多渲染——浪费资源 - 某些引擎（如 Presto/Trino）对 CUBE 有专门优化，但 MySQL 8.0+ 在
ONLY_FULL_GROUP_BY模式下才支持，且不支持超过 10 个分组表达式 - 调试时，用
EXPLAIN看执行计划，CUBE 往往触发“HashAgg on multiple grouping sets”，而 GROUPING SETS 更易被拆解为并行小任务
CUBE 性能崩掉的临界点在哪？
不是数据量大才慢，而是维度数增加后，组合爆炸让内存和 CPU 压力陡增——5 个维度就是 32 种分组，8 个维度就是 256 种。
- 真实业务中，超过 4 个维度就该警惕：即使每维只有 2–3 个取值，CUBE 也会生成大量空组合（比如“西藏+海鲜+凌晨+iOS+新客”根本不存在）
- 避免在宽表上直接 CUBE 所有字段；先用
WHERE过滤高频有效组合，再聚合 - 若需高频下钻，优先建物化视图（如 PostgreSQL 的
MATERIALIZED VIEW）或预计算立方体（如 Apache Kylin），而不是每次查都跑 CUBE - 注意 NULL 值分布：如果某列 NULL 率 >30%，CUBE 会额外生成大量含 NULL 的无效分组行，建议提前清洗或用
COALESCE(col, 'UNKNOWN')归一化
真正难的不是写出 CUBE 语句，而是判断哪些维度该进、哪些该筛、哪些该预处理——它暴露的是你对业务数据稀疏性和聚合意图的理解深度。
