grouping sets语法必须套两层括号，外层括号包裹多个小括号元组，如grouping sets ((dept), (region), (dept, region), ())；漏外层括号会报错，空括号()表示全表总计，且需配合grouping()函数区分占位null与真实null。
GROUPING SETS 语法必须套两层括号，写错直接报错
SQL Server 要求 GROUPING SETS 后必须紧跟一对外层圆括号，里面再包裹若干个元组（每个元组也用小括号）。常见错误是漏掉外层括号，比如写成 GROUP BY GROUPING SETS (dept, region) —— 这会触发 ERROR 1064 (42000)。正确写法是：GROUP BY GROUPING SETS ((dept), (region), (dept, region), ())。
空括号 () 表示全表总计，不能省略；多个元组之间用逗号分隔，末尾不加逗号；所有字段名必须在 SELECT 列表中显式出现，否则报 Column is invalid in the select list 错误。
必须配合 GROUPING() 函数区分 NULL 是占位符还是真实数据
当某列未参与当前分组时，SQL Server 会填入 NULL，但这和原始数据里的 NULL 完全无法分辨。直接用 WHERE dept IS NULL 会同时过滤掉真实为 NULL 的记录和所有按 region 分组的行（因为 dept 在那些行里是占位 NULL）。
-
GROUPING(dept)返回1→ 该行中dept是因未参与分组而被折叠的占位符 -
GROUPING(dept)返回0→dept是原始数据值（含真实NULL）
所以展示时不能用 ISNULL(dept, '总计')，得写成：CASE WHEN GROUPING(dept) = 1 THEN '总计' ELSE dept END AS dept_label。多列判断要分别调用，比如 GROUPING(dept) + GROUPING(region) = 2 表示两者都被折叠。
执行计划里看到多个 HashAggregate 就说明没省扫描
GROUPING SETS 不是优化器自动合并计算的“智能聚合”，它本质就是把每个元组当作独立 GROUP BY 执行，最后 UNION ALL。如果 EXPLAIN 或执行计划里出现多个 HashAggregate 或 Stream Aggregate 节点，且都指向同一张表的全量扫描，说明数据库没复用中间结果——性能和写三个独立查询几乎一样。
实操建议：
- 优先给最宽组合建复合索引，例如
GROUPING SETS ((a), (b), (a,b,c))，索引应为(a,b,c)，让优化器能从一个索引里“截取”出更粗粒度的分组 - 避免混用
ROLLUP或CUBE，SQL Server 虽支持混合写法，但语义难维护，且不同版本对GROUPING_ID()行为有差异 - 维度超过 3 个、组合数 > 8 时，放弃
GROUPING SETS，改用临时表 + 应用层合并，反而更可控
MySQL 用户别试，它根本不支持 GROUPING SETS
截至 MySQL 8.4，GROUPING SETS 仍属于未实现特性。你写进去会立刻报错：ERROR 1064 (42000): You have an error in your SQL syntax。PostgreSQL 9.5+、SQL Server 2008+、Oracle 9i+ 和 Hive 3.1+ 支持；Trino/Presto 也支持，但 PrestoDB 旧版可能行为不一致。
如果你在跨数据库迁移或写通用脚本，别依赖 GROUPING() 或 GROUPING_ID() —— MySQL 完全不认这两个函数，连语法解析都过不去。真要兼容，只能回到 UNION ALL + 多次 GROUP BY 的写法。
最易被忽略的一点：即使语法跑通，GROUPING SETS 输出的行序是不确定的。SQL Server 不保证各分组集之间的顺序，ORDER BY 必须显式写全字段并处理 GROUPING() 值，否则“总计行”可能插在中间，报表对不上。
