grouping sets 必须双层括号，如group by grouping sets ((dept), (region), (dept, region), ())；单层或括号缺失会报错；null需用grouping()而非is null判断；多维组合性能随维度指数增长。
GROUPING SETS 语法必须套两层括号，写错就报错
直接写 GROUP BY GROUPING SETS (dept, region) 会触发 SQL Server 报错 Incorrect syntax near ','。它要求每个分组维度必须是独立元组，外层再用一对括号包裹全部元组。
正确写法是：GROUP BY GROUPING SETS ((dept), (region), (dept, region), ())。其中：
-
(dept)表示只按dept分组 -
(region)表示只按region分组 -
(dept, region)表示联合分组 -
()表示全表聚合（无分组）
漏掉任意一层括号、多加空格或逗号位置错位，SQL Server 都不会执行，而是抛出解析错误。
NULL 到底是真数据还是占位符？靠 GROUPING() 判断，不是 IS NULL
执行 GROUPING SETS ((dept), (region)) 后，结果里 dept 和 region 列会出现大量 NULL。但这些 NULL 不是来自原始数据，而是聚合占位符——比如某行 dept = NULL、region = '华北'，说明这行是按 region 分组的汇总，dept 被折叠了。
如果直接写 WHERE dept IS NULL，会同时过滤掉真实为 NULL 的部门记录和所有按 region 分组的行，逻辑全乱。
必须用 GROUPING() 函数区分：
-
GROUPING(dept) = 1→ 当前行dept是占位符（未参与该组分组） -
GROUPING(dept) = 0→dept是真实分组值 - 多列判断要分开调用：
GROUPING(dept) + GROUPING(region) = 2表示两者都被折叠（即全表总计行）
性能瓶颈常在重复扫描，别指望数据库自动复用中间结果
GROUPING SETS 不是优化器，它只是语法糖，底层等价于多个 GROUP BY + UNION ALL。SQL Server 不会把 (dept, region) 的哈希表复用到 (dept) 的计算中——除非你手动建好覆盖最宽组合的索引。
实操建议：
- 用
EXPLAIN或执行计划看是否有多个Hash Aggregate节点；有，就说明在重复读表或索引 - 索引应优先覆盖最宽的分组组合，例如
GROUPING SETS ((dept), (region), (dept, region))，建INDEX ON t(dept, region)比单列索引更有效 - 维度超过 3 个（如
(a), (b), (c), (a,b), (a,c), (b,c)）时，扫描次数指数增长，不如拆成应用层多次查询
MySQL 用户注意：8.0.24+ 声称支持但行为不一致，生产环境慎用
SQL Server 和 PostgreSQL 对 GROUPING SETS 的实现稳定且符合标准，但 MySQL 直到 8.0.24 才加入实验性支持，且存在关键差异：
- 不支持空括号
()，写上去会报错ERROR 1064 (42000) -
GROUPING()函数返回值含义与 SQL Server 不同，部分版本始终返回 0 - 混合使用
ROLLUP和GROUPING SETS可能直接拒绝解析
如果你的报表服务同时对接 SQL Server 和 MySQL，不要试图写“兼容”SQL——要么统一用 SQL Server，要么在应用层做分支处理。
真正麻烦的不是写对语法，而是后续所有涉及展示、筛选、导出的逻辑都得适配 GROUPING() 的位掩码语义。漏判一个 GROUPING(dept)，报表里的「小计」就会混进脏数据。
