CUBE生成所有维度子集组合（含空集），如CUBE(a,b,c)产生8组：()、(a)、(b)、(c)、(a,b)、(a,c)、(b,c)、(a,b,c)，其中()为总计行，NULL表示该维被折叠，需用GROUPING()区分语义，避免误判为脏数据。
SQL CUBE 生成的组合到底包含哪些
CUBE 不是简单地把所有维度列两两排列，而是生成所有可能的子集组合（含空集），即对 CUBE(a, b, c) 会产出 2³ = 8 组分组：()、(a)、(b)、(c)、(a,b)、(a,c)、(b,c)、(a,b,c)。其中 () 对应总计行（全 NULL），其余每组对应一个聚合粒度。
常见误解是以为 CUBE 等价于多次 GROUP BY UNION，但实际它由优化器统一计算，性能通常优于手工拼接；不过也正因如此，若维度列存在大量 NULL 或高基数，CUBE 的中间结果集可能急剧膨胀。
- 维度顺序不影响组合数量，但影响
GROUPING()函数返回值的位掩码解释（从左到右对应低位到高位） -
GROUPING_ID(a,b,c)返回 0–7 的整数，可用来过滤特定层级，比如只取“按地区+产品汇总”（即 a,b 非空、c 为 NULL 且被 CUBE 视为分组依据）时，GROUPING_ID(a,b,c) = 1表示仅 c 被折叠 - PostgreSQL 14+ 支持
CUBE，MySQL 直到 8.0.33 仍不支持，需用GROUPING SETS模拟或应用层补全
如何避免 CUBE 输出中出现大量重复 NULL 值
CUBE 输出里每个字段都可能出现 NULL，但并非所有 NULL 都表示“缺失数据”——它们是 CUBE 标记“该维度未参与当前分组”的方式。直接 SELECT * FROM (...) WITH CUBE 容易让业务方误读。
必须配合 GROUPING() 或 GROUPING_ID() 判断 NULL 的语义。例如：GROUPING(region) = 1 表示这行是 region 维度被折叠后的汇总，此时 region 字段值为 NULL 是合理的，不是脏数据。
- 别用
IS NULL直接过滤或替换 CUBE 结果中的 NULL，否则会误删合法汇总行 - 推荐在 SELECT 列表中用
CASE WHEN GROUPING(region) = 1 THEN 'ALL_REGIONS' ELSE region END AS region做语义化处理 - 如果某维度列本身允许 NULL 值（如 region = NULL 表示未知），CUBE 无法区分它是原始 NULL 还是折叠 NULL —— 此时必须提前清洗或改用其他标识（如 '
'）
CUBE 和 ROLLUP、GROUPING SETS 的关键区别在哪
ROLLUP(a,b,c) 只生成“前缀组合”：(a,b,c)、(a,b)、(a)、()，适合有天然层次关系的维度（如年→季度→月）；而 CUBE 是全组合，无序且更重；GROUPING SETS 则完全手动指定，最灵活也最可控。
当只需要部分交叉（比如只要 (a,b)、(a,c)、() 三组），硬写 CUBE(a,b,c) 会多算 5 组无用结果，拖慢查询、增加网络传输量。这时 GROUPING SETS ((a,b), (a,c), ()) 是更优解。
- Oracle/SQL Server 中
CUBE和ROLLUP都是语法糖，底层都转成GROUPING SETS - 某些场景下
ROLLUP能利用索引排序优势加速，CUBE因组合无序，基本无法利用索引下推 - 如果后续要加 HAVING 过滤，
GROUPING SETS更容易定位目标分组条件，CUBE得靠GROUPING_ID()掩码判断，可读性差
为什么 CUBE 查询在大数据量下容易 OOM 或超时
CUBE 的计算本质是构建笛卡尔积级别的分组键空间。假设有 4 个维度，各自唯一值数分别为 100、50、20、10，则 CUBE 最多产生 2⁴ × 100 × 50 × 20 × 10 = 8000 万行中间结果 —— 这还没算聚合函数本身的内存开销。
数据库通常不会预先物化全部组合，但会在内存中维护多个哈希表或排序缓冲区来并行处理不同分组粒度，极易触发 spill-to-disk 或直接被内存策略 kill。
- 务必在 CUBE 前加 WHERE 过滤，不要指望“先 CUBE 再 WHERE”能优化 —— 大多数引擎仍会为所有组合分配资源
- 对高基数维度（如 user_id），禁止直接放入 CUBE；应先按业务逻辑聚合成低粒度（如 region + device_type），再对其 CUBE
- StarRocks、Doris 等 MPP 引擎支持
SET enable_cbo = false强制走分布式哈希聚合，比默认计划更稳；但 PostgreSQL 单机版遇到大 CUBE 基本只能调大work_mem或拆成多次查询
实际用 CUBE 时，最麻烦的往往不是语法写不对，而是没想清楚“到底要哪几层交叉”以及“NULL 到底代表什么”。一旦维度数超过 3 个，就该本能怀疑是不是设计上该换思路了。
