grouping sets不是函数，而是group by的子句，必须写成group by grouping sets ((col1), (col1,col2), ())形式；需配合grouping()函数区分null是真实值还是分组占位，mysql目前不支持。
GROUPING SETS 不是函数，别写成 GROUPING_SETS()
很多人一看到名字带“GROUPING”，就下意识当成函数调用，比如写成 GROUP BY GROUPING_SETS(col1, col2) 或更糟的 GROUP BY GROUPING_SETS(col1), GROUPING_SETS(col2)。这会直接报错：ERROR 1064（MySQL）或类似语法错误（SQL Server/PostgreSQL）。GROUPING SETS 是 GROUP BY 的子句，必须用括号嵌套多个元组，每个元组是一组分组维度。
正确写法只有一种结构：
GROUP BY GROUPING SETS ( (col_a), (col_b, col_c), () )
- 每个分组维度组合必须用小括号包裹，哪怕只有一个列
- 空括号
()表示全表聚合（即总计行），不能省略 - 逗号分隔不同分组集，不是列之间用逗号
怎么让 NULL 区分“真实缺失”和“分组占位”
执行 GROUPING SETS 后，结果里大量出现 NULL——但你无法单靠值判断这是原始数据里的空值，还是数据库自动填的占位符。比如 region = NULL 可能表示“该销售记录地区未知”，也可能是“当前行是按产品汇总的，region 不参与分组所以被置空”。
必须配合 GROUPING() 函数才能可靠识别：
-
GROUPING(region)返回1→ 该行未按region分组，NULL是占位符 -
GROUPING(region)返回0→region参与了分组，NULL来自原始数据 - 多列时可用
GROUPING_ID(col1, col2, col3)得到唯一整数编码，比逐个GROUPING()更紧凑
别依赖 COALESCE(region, 'ALL_REGION') 做展示替代——它掩盖了语义差异，下游逻辑若要过滤“仅地区小计”，就会出错。
MySQL 用户请立刻停手：它目前不支持 GROUPING SETS
截至 MySQL 8.4（2026年最新稳定版），GROUPING SETS 仍未实现。任何尝试都会触发 ERROR 1064，且没有兼容替代语法。不要试图用视图、CTE 或存储过程模拟——性能差、维护难、语义不等价。
可行路径只有两个：
- 迁移到支持的引擎：SQL Server 2008+、PostgreSQL 9.5+、Trino/Presto、Hive 2.0+、Oracle 12c+
- 退回到传统方案：用
UNION ALL拼多个GROUP BY查询，但注意显式加ORDER BY控制行序，否则结果顺序不可控
尤其注意 Hive 和 Presto 虽然支持，但 GROUPING() 函数在 Presto 中行为更严格——若 GROUP BY 子句里混写了普通列（非 GROUPING SETS），GROUPING() 会报错。
括号嵌套层级和性能影响很实际
写 GROUPING SETS ((a,b), (a), (b), ()) 和写 GROUPING SETS ((a,b), (a,c), (b)) 看似只是组合不同，但执行计划差异很大。数据库优化器会基于所有分组集合并估算一次全表扫描，再分流计算；如果某组维度（如 (a, b, c, d)）涉及高基数列，可能导致内存溢出或 spill to disk。
实操建议：
- 避免无意义组合：比如业务只要“部门+地区”和“部门”，就别硬加一个
(地区)——除非真需要 - 把高频访问的细粒度组合放前面（如
(dept, region, city)），部分引擎会优先输出 - 在 SQL Server 中，启用
QUERYTRACEON 9481可观察是否走并行分组；PostgreSQL 则需检查EXPLAIN ANALYZE中的GroupAggregate节点是否复用扫描
最易被忽略的一点：空括号 () 对应的全表聚合，会强制触发一次完整扫描，即使其他分组集已覆盖全部数据——它无法被优化掉。
