cube仅生成多维分组聚合结果而非交叉表,因其输出为含null的扁平化行集(如(region,product)、(region,null)等),null表示该维汇总而非缺失;需配合case+sum或pivot才能转为行列分明的交叉表。

CUBE 本身不生成“报表”,它只生成多维分组聚合结果;要得到可读交叉表,必须配合条件聚合或 PIVOT(取决于数据库)
为什么直接 SELECT … GROUP BY CUBE(...) 看起来不像交叉表?
CUBE 返回的是所有维度组合的扁平化行集,比如对 region 和 product 做 CUBE,会返回:(region, product)、(region, NULL)、(NULL, product)、(NULL, NULL) 四类行——它不自动把 product 拆成列,也不补空格/对齐。你看到的是一堆带 NULL 的聚合行,不是 Excel 那种行列分明的交叉表。
-
NULL在 CUBE 结果中代表“该维度全部”,不是缺失值,别用WHERE直接过滤掉,否则会丢汇总行 - PostgreSQL / SQL Server / Oracle 都支持 CUBE,但 MySQL 8.0+ 才支持(且不支持 ROLLUP/CUBE 语法糖,需用 GROUPING SETS 模拟)
- CUBE 的输出顺序不保证,
GROUPING()函数才是识别“哪一维被汇总”的唯一可靠方式
用 CASE + SUM 实现手动交叉表(兼容性最强)
这是最可控的方式:先用 CUBE 得到全维度聚合,再用条件聚合把某个维度“转成列”。假设统计各 region 下各 product 的销售额总和,并含小计与总计:
SELECT COALESCE(region, '总计') AS region, SUM(CASE WHEN product = 'A' THEN amount ELSE 0 END) AS A, SUM(CASE WHEN product = 'B' THEN amount ELSE 0 END) AS B, SUM(CASE WHEN product = 'C' THEN amount ELSE 0 END) AS C, SUM(amount) AS 小计 FROM sales GROUP BY CUBE (region, product) HAVING GROUPING(product) = 1 -- 只取 region 维度有值、product 被汇总的行(即每 region 一行 + 总计行) ORDER BY GROUPING(region), region;
-
GROUPING(product) = 1表示这一行的product是 CUBE 生成的汇总(即NULL),我们只保留这些行来构造“行头” -
COALESCE(region, '总计')把最末的region = NULL行显式标为“总计”,避免显示为NULL - 若
product值动态变化(如新增 D 类),这段 SQL 必须手动加CASE分支——无法自动适配
SQL Server 用 PIVOT 配合 CUBE 更简洁(但不可移植)
如果你在 SQL Server 上,可以先 CUBE 得到基础聚合,再用 PIVOT 转置。注意:PIVOT 要求源数据中不能有重复的 (region, product) 组合,所以 CUBE 后得先确保每个 (region, product) 只有一行(通常已满足):
SELECT *
FROM (
SELECT
COALESCE(region, '总计') AS region,
COALESCE(product, '全部') AS product,
SUM(amount) AS amt
FROM sales
GROUP BY CUBE(region, product)
) t
PIVOT (SUM(amt) FOR product IN ([A], [B], [C], [全部])) p;
-
PIVOT的IN列表必须写死,不支持子查询或变量,动态列仍需拼接 SQL -
[全部]对应product IS NULL的行,即每个 region 下的行内小计;而region = NULL的行会出现在region = '总计'中 - Oracle 用
PIVOT语法类似,但 PostgreSQL 没原生 PIVOT,得靠crosstab()扩展函数,且要求输入严格有序
真正难的不是写出 CUBE,而是决定哪些维度该进 CUBE、哪些该被转成列、哪些该被过滤——因为 CUBE 的组合数是 2ⁿ,5 个字段就是 32 组,结果集容易爆炸。另外,GROUPING() 的返回值是位掩码,多人协作时容易误判哪一维被汇总,建议封装成带注释的视图或 CTE。










