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。
