GROUPING SETS语法必须写成GROUP BY GROUPING SETS ((a,b), (a), ())形式，外层括号和内部元组缺一不可；须配合GROUPING()函数区分占位NULL与真实NULL；MySQL不支持，需用UNION ALL模拟；ROLLUP/CUBE仅为特例，灵活性不及GROUPING SETS。
GROUPING SETS 语法必须写成 GROUP BY GROUPING SETS ((a,b), (a), ()) 形式
它不是函数，不能加括号调用，也不能省略外层括号或元组结构。常见错误包括：GROUPING_SETS()、GROUPING SETS (a, b)、GROUP BY GROUPING SETS()——这些都会直接报错，比如 MySQL 报 ERROR 1064，SQL Server 报 Incorrect syntax near 'GROUPING'。
正确写法强调两点：外层 GROUPING SETS 后必须紧跟一对圆括号；括号内是用逗号分隔的**元组列表**，每个元组自身也用小括号包裹：
-
GROUP BY GROUPING SETS ((region, city), (region), ())✅ 生成三组：地区+城市、仅地区、全表总计 -
GROUP BY GROUPING SETS ((region), (city), ())✅ 允许跳过组合，不强制层级 -
GROUP BY GROUPING SETS ((region, city, store))✅ 等价于普通GROUP BY region, city, store，但为后续扩展留接口
必须配合 GROUPING() 判断 NULL 是占位符还是真实值
只靠 IS NULL 区分汇总行完全不可靠——原始数据里 region 本就可能为 NULL。真正能定位“该行是否按 region 分组”的，只有 GROUPING(region)：
-
GROUPING(region) = 1→ 当前行未参与region分组，字段值为系统填充的占位 NULL -
GROUPING(region) = 0→region参与了当前分组，值为真实数据（哪怕刚好是 NULL） - 多列时可组合判断：
CASE WHEN GROUPING(region)=1 AND GROUPING(city)=1 THEN '总计' WHEN GROUPING(region)=1 THEN '城市汇总' ... END
Hive/SparkSQL 还支持 GROUPING__ID（双下划线），返回整型掩码，比逐列写 GROUPING() 更紧凑，但语义不如前者直观。
MySQL 不支持 GROUPING SETS，别硬套
截至 MySQL 8.4（2026年最新稳定版），该语法仍被拒绝。执行会直接报 ERROR 1064，没有任何降级提示。PostgreSQL 9.5+、SQL Server 2008+、Oracle 9i+、Trino/Presto、Hive/SparkSQL 均支持。
如果必须在 MySQL 环境实现类似效果，只能退回到 UNION ALL + 多个 GROUP BY，但要注意：
- 各子句字段类型必须严格一致，否则
UNION ALL会失败 - 无法使用
GROUPING()，前端只能靠字符串标记（如COALESCE(region, '小计')），一旦业务中真有region = '小计'就彻底混淆 - 优化器难复用执行计划，百万级数据下性能通常比单次
GROUPING SETS差 3 倍以上
ROLLUP 和 CUBE 是 GROUPING SETS 的特例，但不可替代
ROLLUP(a,b) 等价于 GROUPING SETS ((a,b), (a), ())，CUBE(a,b) 等价于 GROUPING SETS ((a,b), (a), (b), ())。它们本质是语法糖，但有明显局限：
-
ROLLUP对列序敏感：ROLLUP(a,b)≠ROLLUP(b,a)，而GROUPING SETS中元组顺序无关 - 需要跳过中间层时（比如只要
(dept)和()，不要(dept, role)），ROLLUP或CUBE会多出无用行，还得加HAVING过滤，干扰优化器 -
CUBE组合数指数增长：CUBE(a,b,c,d)生成 16 种分组，维度一多就爆炸，而GROUPING SETS只声明你需要的那几个
真正容易被忽略的是：即使语法写对了，没用 GROUPING() 标注，报表使用者根本分不清某行的 NULL 是“华东区小计”还是“全公司总计”——数据库不会主动帮你打标签，这层语义必须由 SQL 显式承担。
