GROUP BY CUBE 生成 2ⁿ 行（n 为分组列数），即所有维度组合的幂集，含全表聚合；例如 3 列得 8 行，且每行用 NULL 标识未参与分组的维度，需配合 GROUPING() 区分汇总占位与真实 NULL。
GROUP BY CUBE 会生成多少行？先算清楚再执行
CUBE 的结果行数是 2ⁿ（n 是 GROUP BY 中的列数），不是“大概多一点”。3 列 → 8 行，4 列 → 16 行，7 列 → 128 行，10 列 → 1024 行。这还不算原始数据膨胀带来的内存/磁盘压力。
实际执行前务必估算：
- 用
SELECT COUNT(*) FROM table GROUP BY CUBE(col1, col2, col3)测行数，别直接套生产 SQL - 高基数列（如
user_id、order_no、毫秒级created_at）绝对不能进 CUBE —— 一行变百万行不是夸张 - PostgreSQL 可能报
out of memory或disk is full；SQL Server 默认不排序，但客户端渲染时容易卡死
NULL 到底是数据缺失，还是 CUBE 汇总占位？用 GROUPING() 区分
CUBE 产生的 NULL 和真实数据里的 NULL 在结果里长得一模一样，但语义完全不同。不加判断就 COALESCE(col, 'N/A')，会把汇总行误标为“缺失”。
正确做法是配合 GROUPING() 函数：
-
GROUPING(region) = 1→ 这行的region是汇总占位（即“所有 region”） -
GROUPING(region) = 0→ 这行的region是真实值（哪怕它本身是 NULL） - 常用组合：
COALESCE(NULLIF(region, ''), 'ALL')+GROUPING(region)联合判断更稳
示例片段：
SELECT COALESCE(region, 'ALL') AS region, COALESCE(product, 'ALL') AS product, SUM(sales) AS total_sales, GROUPING(region) AS g_region, GROUPING(product) AS g_product FROM sales_data GROUP BY CUBE(region, product);
CUBE 与 ROLLUP、GROUPING SETS 不是替代关系，而是集合关系
CUBE(a,b) 等价于 GROUPING SETS((a,b), (a), (b), ())，而 ROLLUP(a,b) 等价于 GROUPING SETS((a,b), (a), ())。如果你只需要“按年→按年+月→总计”，用 ROLLUP(year, month) 更精准、更省资源。
选哪个，看业务逻辑是否真需要“全排列”：
- 要“华东+手机”和“2024+手机”两个小计？→ 必须用
CUBE - 只要“全国→省→市”树状上卷？→
ROLLUP更合适，且结果可预测 - 只想要 3 种特定组合（比如 (a,b), (c), (d,e)）？→ 直接写
GROUPING SETS，避免 CUBE 生成冗余 2ⁿ−3 行
ORDER BY 和 HAVING 在 CUBE 查询里容易失效
ORDER BY 对 CUBE 结果排序时，NULL 值默认排最前（PostgreSQL/SQL Server），但不同引擎行为不一致；HAVING 过滤的是聚合后结果，但 CUBE 生成的每一行都经过聚合，所以 HAVING SUM(sales) > 1000 会同时过滤明细行和汇总行——你可能只想筛掉某些维度的小计。
更可控的做法：
- 用子查询或 CTE 先加
GROUPING()标识列，再在外部WHERE过滤，比如WHERE g_region = 0 AND g_product = 0只留明细 - 排序时显式处理
NULL：ORDER BY GROUPING(region), region, GROUPING(product), product - Databricks SQL / SparkSQL 中
CUBE必须是GROUP BY子句中唯一的表达式，不能混用普通列
CUBE 的威力不在“能跑出来”，而在“跑出来之后你还知道哪一行代表什么”。漏掉 GROUPING() 或盲目加 COALESCE 是线上报表出错最常见的原因。
