CUBE是GROUPING SETS的语法糖，显式展开所有维度的幂集（含空集），而GROUPING SETS可自定义组合；CUBE需配合GROUPING()函数区分NULL值与汇总行，且存在兼容性与性能限制。
什么是CUBE，它和GROUPING SETS有什么本质区别
CUBE不是“自动帮你算所有组合”的黑箱，而是GROUPING SETS的语法糖——它会**显式展开**你列出的所有维度的幂集（含空集）。比如CUBE(a, b, c)等价于GROUPING SETS ((a,b,c), (a,b), (a,c), (b,c), (a), (b), (c), ())。空集对应全表总计行，这点常被忽略。
关键判断：如果你只想要部分组合（比如不要单独的(a)，只要(a,b)、(a)、()），就别用CUBE，直接写GROUPING SETS更可控。
如何写出可读、可维护的CUBE查询
直接写SELECT a, b, SUM(sales) FROM t GROUP BY CUBE(a, b)看似简单，但结果里a或b为NULL时，你无法区分这是“该维度未参与分组”还是“原始数据里真有NULL值”。必须配合GROUPING()函数做标记：
SELECT CASE WHEN GROUPING(city) = 1 THEN 'ALL_CITIES' ELSE city END AS city, CASE WHEN GROUPING(product) = 1 THEN 'ALL_PRODUCTS' ELSE product END AS product, SUM(sales) FROM sales GROUP BY CUBE(city, product);
-
GROUPING(col)返回1表示该列在当前行分组中被“折叠”，即属于CUBE生成的汇总行 - 别依赖
IS NULL判断汇总行——原始数据本身可能含NULL，会混淆 - 维度顺序影响结果行数（n个维度 → 2ⁿ 行），3维以上时务必确认业务是否真需要全部2ⁿ种组合
CUBE在不同数据库中的兼容性陷阱
PostgreSQL、SQL Server、Oracle都支持标准CUBE；MySQL 8.0+才支持，且不支持GROUPING()函数（只能靠IFNULL() + 人工标记）；SQLite完全不支持。
常见报错：
-
ERROR: function grouping(text) does not exist（PostgreSQL里对非分组列用了GROUPING()）→ 只能对GROUP BY子句中出现的列调用 -
Unknown column 'city' in 'field list'（MySQL里没加GROUP BY却用了CUBE）→ MySQL强制要求GROUP BY存在 - 聚合字段未出现在
SELECT列表中 → 所有非聚合列必须是GROUP BY的一部分，或用GROUPING()包裹
性能问题比想象中更实际
CUBE不是加个关键字就完事。它会强制计算2ⁿ个分组，内存和CPU消耗随维度数指数增长。5个维度就是32个分组，若底层表有千万行，执行计划可能退化成多次全表扫描。
- 先用
EXPLAIN看是否走了索引——CUBE通常无法利用复合索引的全部列 - 避免在高基数列（如
user_id）上用CUBE，优先选低基数维度（如status、region） - 如果只是要“按A汇总 + 按B汇总 + 全部汇总”，用
UNION ALL三个独立GROUP BY反而更快，也更容易缓存
真正难的从来不是写对语法，而是想清楚：业务到底需要哪几层汇总？有没有更轻量的替代路径？
