GROUPING SETS 不支持嵌套子查询，必须用子查询预处理数据后再在外层使用；它仅接受列名、常量或简单表达式，不可嵌入 SELECT、窗口函数等，否则报错。
不能把聚合子查询直接塞进 GROUPING SETS 的括号里——语法报错是必然的，不是你写得不够熟。
GROUPING SETS 本身不接受子查询表达式
你写的 GROUPING SETS ((dept), (SELECT region FROM dim_region WHERE id = t.region_id)) 这类结构，所有主流数据库（PostgreSQL、SQL Server、Oracle、MySQL 8.0.24+）都会立刻报错，典型错误是：ERROR: syntax error at or near "SELECT" 或 near "GROUPING": syntax error。原因很直接：GROUPING SETS 是 GROUP BY 的子句，只允许列名、常量或简单表达式（如 COALESCE(dept, '[N/A]')），不能嵌套 SELECT、不能调用子查询、不能放窗口函数。
正确做法：子查询预处理，外层只管分组
真正能跑通的路径，是把“需要聚合计算的维度”提前算好，再喂给外层 GROUPING SETS。比如你想按「部门」和「部门所在大区」（需从地区 ID 关联维表查出）统计销售额：
- 子查询里完成 JOIN + 映射：用
LEFT JOIN dim_region ON t.region_id = r.id拿到r.area，并用COALESCE(r.area, '[Unknown]')处理 NULL - 子查询必须显式别名，例如
AS t，否则 PostgreSQL/SQL Server 会报missing alias - 外层 GROUPING SETS 只能引用子查询输出的列名，比如
(dept)、(area)、(dept, area)，不能写(t.dept)或(r.area) - 如果子查询含耗时操作（如多表 JOIN + 窗口函数），建议用
WITH t AS MATERIALIZED (...) SELECT ... FROM t GROUP BY GROUPING SETS ...（PostgreSQL 12+），避免重复执行
GROUPING() 必须配套用，否则 NULL 无法区分
子查询中已用 COALESCE(area, '[Unknown]') 把原始 NULL 转成占位符，外层 GROUPING(area) 才能准确返回 1 表示“这是 area 维度的小计行”，而不是误判为“原始数据为空”。常见错误是只靠 area IS NULL 做判断，结果把小计行和脏数据混在一起。
示例片段：
WITH t AS MATERIALIZED (
SELECT
COALESCE(d.name, '[Unknown]') AS dept,
COALESCE(r.area, '[Unknown]') AS area,
t.sales
FROM fact_sales t
LEFT JOIN dim_dept d ON t.dept_id = d.id
LEFT JOIN dim_region r ON t.region_id = r.id
)
SELECT
CASE WHEN GROUPING(dept) = 1 THEN '总计' ELSE dept END AS dept_label,
CASE WHEN GROUPING(area) = 1 THEN '全部大区' ELSE area END AS area_label,
SUM(sales) AS total_sales
FROM t
GROUP BY GROUPING SETS ((dept), (area), ());
<h3>兼容性差时，用 UNION ALL 替代 GROUPING SETS</h3>
<p>MySQL 8.0 早期版本或旧版 Hive 对 GROUPING SETS 支持不稳定，<code>GROUPING()</code> 可能不可用。这时更稳妥的做法是手动拆成多个子查询再 UNION ALL：</p>
- 每个子查询只做一层 GROUP BY，比如
SELECT dept, NULL AS area, SUM(sales) FROM t GROUP BY dept - 所有子查询 SELECT 列数、类型、顺序必须严格一致，否则 UNION ALL 会失败
- 记得在最外层加
ORDER BY控制小计/总计位置，因为 UNION ALL 不保证顺序
本质没变：还是分步聚合，只是把语法层面的 GROUPING SETS 拆成了逻辑等价的手动拼接。
最容易被忽略的一点：GROUPING SETS 的性能不取决于你写了几个 grouping set，而取决于子查询是否物化、原始 NULL 是否清理干净、以及 GROUPING() 是否被正确用于语义识别——这三处任一出错，结果就不可信，优化也无从谈起。
