SQL子查询不适合多维度聚合，因其导致性能崩塌、逻辑混乱和结果错位；应优先使用GROUPING SETS、ROLLUP或CUBE。
直接说结论：SQL子查询本身不是做多维度聚合的合适工具，它容易导致性能崩塌、逻辑混乱和结果错位；真要实现多维度聚合，优先用 GROUPING SETS、ROLLUP 或 CUBE，而不是靠多层嵌套子查询硬扛。
为什么子查询做多维聚合会出问题
子查询天然是一次一维的计算单元，强行用它拼多维结果，本质是把多个独立聚合“缝合”在一起。这带来三个硬伤：
- 同一张大表被反复扫描多次——比如你写三个子查询分别按省份、按品类、按省份+品类聚合，引擎就得读源表三遍，I/O和Shuffle开销翻倍
- 字段对齐靠手工补
NULL和常量，稍不注意就会类型不匹配或列数错位，报错信息像UNION ALL: number of columns mismatch - 无法表达“空组合”（比如全量总计），你得额外写一个不带
GROUP BY的子查询，再用UNION ALL接上去，维护成本指数级上升
GROUPING SETS 替代子查询的实操写法
用 GROUPING SETS 一行就能替代原来需要 4～5 个子查询 + UNION ALL 的逻辑。关键点在于：
-
GROUP BY后必须列出所有可能用到的维度字段，哪怕某个分组组合里没用到它 -
GROUPING SETS里的每个括号代表一个分组粒度，空括号()表示全量总计 - 务必加上
GROUPING__ID字段，它能帮你识别每行属于哪个分组组合，避免把“省份=浙江”和“品类=手机”的结果误认为同一层级
例如想同时获取：全国总计、各省份、各省+各品类、各品类——写法是：
SELECT province, category, SUM(sales_amt) AS total_sales, GROUPING__ID FROM sales_table GROUP BY province, category GROUPING SETS ( (), (province), (province, category), (category) );
Hive 和 Presto 对 GROUPING SETS 的兼容性差异
别假设写了就能跑通，不同引擎对 GROUPING SETS 的支持程度差别很大：
- Hive 3.1+ 完全支持，且优化器会自动合并 Shuffle，性能提升明显
- Presto（包括 Trino）支持语法，但
GROUPING__ID返回的是二进制位掩码，不是 Hive 那种连续整数，需要用bitwise_and()手动解析 - Spark SQL 3.0+ 支持，但早期版本（如 2.x）会直接报错
Unsupported operation: GROUPING SETS - MySQL 和 PostgreSQL 原生不支持
GROUPING SETS，强行用就得退回UNION ALL或改用ROLLUP
当真没法用 GROUPING SETS 时的兜底方案
如果环境受限（比如老版本 Hive 或 MySQL），又不想写一堆子查询，可以折中用 ROLLUP：
-
ROLLUP(a, b, c)等价于GROUPING SETS ((a,b,c), (a,b), (a), ())，适合有明确层级关系的维度（如省→市→区） - 它比手写子查询少写 3～4 行，也不用担心字段对齐，但无法表达“跨层级组合”，比如不能同时要（省+品类）和（市+渠道）
- 注意
ROLLUP生成的NULL是占位符，不是真实数据缺失，要用GROUPING()函数区分
真正难搞的，是那些维度之间没有天然层级、又必须任意交叉组合的场景——这时候硬用子查询不是懒，是给自己埋雷。要么升级引擎，要么提前在 ETL 层物化好常用组合，别指望一条 SQL 兜底所有业务口径。
