group by cube 生成的逻辑分组数严格等于 2ⁿ（n 为列数），如 cube(a,b,c) 必然产生 8 种分组组合；实际返回行数取决于各列真实取值组合数，并非固定 2ⁿ，需用 grouping() 区分 null 是真实值还是汇总占位符。
GROUP BY CUBE 会生成多少行结果？
结果行数不是“大概多一点”，而是严格等于 2ⁿ（n 是 CUBE 中列出的列数），每种组合都独立计算。例如 GROUP BY CUBE(a, b, c) 必然产出 8 行逻辑分组（含全表汇总），哪怕某列只有 1 个值，也照样算进 2³ 里。
但实际返回行数 ≠ 2ⁿ，它还取决于各列的**真实取值组合数**。比如 a 有 10 值、b 有 5 值、c 有 3 值，理论最大输出是 10×5×3 × 8 = 1200 行；若其中很多组合根本不存在（如 (a=5, b=9) 在原始数据中没出现），对应 CUBE 行就不会生成。
常见误判：看到结果里 NULL 多，就以为“漏了数据”——其实那是 CUBE 主动填充的占位符，表示该维度被折叠，不是缺失值。
怎么区分 NULL 是真实值还是汇总占位符？
直接查 region 和 product 都为 NULL 的行，你无法判断它是“region 和 product 都为空的原始记录”，还是“全表汇总行”。必须用 GROUPING() 函数打标：
-
GROUPING(region)返回1→ 当前行的region是汇总占位，不是真实值 -
GROUPING(product)返回0→ 当前行的product是真实分组值 - 两列都返回
1→ 全表聚合（即GROUP BY ()）
配合 COALESCE() 可读性更强：COALESCE(region, 'All Regions') 把占位 NULL 替换成业务可理解的标签，但注意：别在 WHERE 或 HAVING 里对替换后的字符串做过滤——那会绕过 GROUPING() 的语义，导致逻辑错误。
CUBE 在不同数据库里的语法差异
核心行为一致，但关键字写法和兼容性有坑：
- PostgreSQL / SQL Server / BigQuery / Snowflake：直接写
GROUP BY CUBE(col1, col2) - MySQL 8.0+：不支持
CUBE关键字，必须用等价的GROUP BY GROUPING SETS手动展开，例如CUBE(a,b)要写成GROUP BY GROUPING SETS ((a,b), (a), (b), ()) - 旧版 MySQL（
- SQLite：不支持任何分组集语法
执行前务必确认目标数据库版本。一个 CUBE 语句在本地 PostgreSQL 跑通，上线到 MySQL 环境可能直接报错 Unknown keyword 'CUBE'。
为什么 CUBE 查询变慢甚至 OOM？
不是数据量大才慢，而是 CUBE 自身的计算模式导致资源线性膨胀：
- 数据库通常不会复用中间聚合结果，
CUBE(a,b,c)很可能触发 8 次独立哈希分组或排序，而非“一次扫描 + 多路输出” - 高基数列（如
user_id）参与CUBE时，内存中要维护大量哈希桶，容易触发磁盘临时文件（spill to disk），IO 拖垮性能 - 结果集宽（列多）+ 大量
NULL→ 存储引擎页内碎片增加，压缩率下降，网络传输体积翻倍 - 某些数据库（如早期 SQL Server）对
CUBE的执行计划缓存不友好，参数化查询易失效，每次重编译
上线前必须用真实数据量级压测。4 列 CUBE 在百万行表上可能跑出千万级结果行，而开发环境只用千行测试数据，根本暴露不出问题。
