CUBE是SQL中生成所有维度组合聚合的GROUP BY扩展运算符，自动产出2ⁿ种分组（含空集总计）；而普通GROUP BY仅按指定列单一聚合，不生成小计或总计。

什么是CUBE，它和GROUP BY有什么本质区别？ CUBE 是 SQL 标准中用于生成多维组合聚合的运算符，不是函数也不是语法糖。它会在 GROUP BY 基础上，自动补全所有维度列的幂集组合（包括空集），也就是“全维度交叉汇总”。比如对 (a, b, c) 使用 CUBE，实际会等价于手动写出 8 组 GROUP BY： GROUP BY a, b, c GROUP BY a, b GROUP BY a, c GROUP BY b, c GROUP BY a GROUP BY b GROUP BY c GROUP BY ()（即全表聚合） 这直接决定了它的输出行数是 2ⁿ（n 为维度列数），数据量增长极快，三列就是 8 行，五列就是 32 行——别在大表上无过滤地用。

怎么写一个能跑通的CUBE查询？注意NULL陷阱 CUBE 必须跟在 GROUP BY 后面，语法形如：GROUP BY CUBE(col1, col2, ...)。但关键点在于：数据库会用 NULL 标记“该维度未参与聚合”的行，而这个 NULL 是真实值，不是缺失数据。 常见错误是直接 WHERE col1 = 'X' 过滤，结果把所有含 col1 为 NULL 的汇总行（比如按 col2 单独聚合的那批）全干掉了。 正确做法是区分语义：

• 用 GROUPING(col1) 函数判断该列是否属于当前行的“汇总层级”——返回 1 表示是 CUBE 自动生成的汇总行（此时 col1 值为 NULL），返回 0 表示是明细分组
• 想查“只按地区汇总的销售额”，别写 WHERE region IS NULL AND product IS NOT NULL，改用 HAVING GROUPING(region) = 1 AND GROUPING(product) = 0
• 展示时建议用 COALESCE(col1, '总计') 替换 NULL，否则报表里一堆 NULL 容易误读

MySQL 8.0+、PostgreSQL、SQL Server 对CUBE的支持差异 不是所有数据库都原生支持 CUBE：

• MySQL 在 8.0.12+ 才加入 CUBE，且仅支持标准语法 GROUP BY CUBE(...)；5.7 及更早版本完全不识别，强行写会报错 ERROR 1064
• PostgreSQL 从 14 开始支持 CUBE，但需注意它默认不开启 standard_conforming_strings 时可能与字符串字面量冲突（少见但存在）
• SQL Server 支持最久，但要求兼容级别 ≥ 90（即 SQL Server 2005+），且必须用 GROUP BY col1, col2 WITH CUBE 旧语法（不能写 GROUP BY CUBE(...)）
• SQLite、Oracle（用 ROLLUP 和 GROUPING SETS 模拟）、老版本 PostgreSQL 都得靠 UNION ALL 多次 GROUP BY 手动拼，性能差、易出错

为什么COUNT(*)在CUBE结果里经常“不准”？ COUNT(*) 统计的是当前分组内的行数，而 CUBE 的每一行对应不同粒度的分组。例如：

SELECT region, product, COUNT(*) 
FROM sales 
GROUP BY CUBE(region, product);

其中 (NULL, NULL) 行的 COUNT(*) 是全表总行数； (NULL, 'A') 行的 COUNT(*) 是所有地区中 product='A' 的总条数； ('North', NULL) 行的 COUNT(*) 是 North 地区所有产品的总条数。 容易踩坑的是：有人拿这个结果去算“每个地区的平均产品数”，却没意识到 (region, NULL) 行的 COUNT(*) 已经包含了所有产品，而 (region, product) 行只是明细——二者量纲根本不同，不能直接做除法。 真正要算“某地区平均每个产品卖了多少单”，得先用窗口函数或子查询分离层级，或者改用 SUM(CASE WHEN product IS NOT NULL THEN 1 ELSE 0 END) 控制统计范围。 CUBE 的威力在于快速覆盖所有切片组合，但它的 NULL 语义、行列爆炸、跨数据库语法分裂，每一条都得在写之前心里有数。