GROUPING SETS可一次性生成明细、分组小计和全表总计，需配合GROUPING()函数准确识别汇总行，避免用IS NULL误判；括号不可省略，支持精准控制分组组合，性能优于CUBE/ROLLUP。
需要同时输出明细、分组小计和全表总计的场景
比如你要导出一张销售报表，既要看到每个城市每家门店的销售额（明细），又要看到每个城市的汇总（小计），还得有全部销售额（总计）——GROUPING SETS能在一个查询里全搞定，不用拼UNION ALL或跑多次查询。
常见错误是直接用IS NULL判断汇总行：原始数据里字段真可能是NULL，但GROUPING()返回1才代表这是聚合生成的占位值。必须靠GROUPING(dept)和GROUPING(role)组合判断，不能只看字段是否为空。
-
GROUPING SETS ((city), (city, store), ())→ 分别按城市、城市+门店、空组聚合 - 结果中
city IS NULL AND store IS NULL不等于“全表总计”，得查GROUPING(city) = 1 AND GROUPING(store) = 1 - 括号不能省：
GROUPING SETS (city)❌，必须写成GROUPING SETS ((city))
想控制哪些分组组合出现，而不是依赖CUBE或ROLLUP的固定模式
CUBE会生成所有可能组合，ROLLUP只按层级顺序展开，而GROUPING SETS让你手动指定要哪几组——比如只要“部门+岗位”和“全公司总计”，不要“部门总计”或“岗位总计”，GROUPING SETS ((dept, role), ())就能精准命中。
性能上更轻量：数据库只执行你列出来的分组逻辑，不会多算冗余组合。尤其在宽表、高基数列上，避免CUBE爆炸式膨胀。
- 想排除某类中间汇总？直接不写它对应的括号组就行
-
GROUPING SETS (())合法，表示只要全表总计；但GROUPING SETS ()语法错误 - 和
WHERE一起用要小心：提前过滤掉dept IS NOT NULL，会导致“部门小计”行丢失——因为小计行的dept是有值的，但role是NULL，WHERE会误杀
前端需要明确区分汇总行类型来做表格合并或样式处理
BI工具或前端渲染表格时，常需把“总计”“小计”单元格合并、加粗、标颜色。GROUPING()返回的0或1就是最干净的信号源，比用COALESCE硬替换更可靠。
示例：用CASE WHEN GROUPING(city) = 1 THEN '总计' ELSE city END生成可读标签，再配合GROUPING(store)决定是否合并store列——这样前端拿到的就是带语义的结构化数据，不是一堆NULL猜来猜去。
- 别在
SELECT里直接COALESCE(city, '总计')：如果原始city真为NULL，就混了 -
GROUPING()必须和GROUPING SETS配套使用，单独GROUP BY里调用会报错 - PostgreSQL、SQL Server、Oracle、GaussDB(DWS)都支持，但MySQL 8.0+才开始支持，旧版本得换方案
WHERE和HAVING容易踩的边界问题
WHERE在分组前过滤，HAVING在分组后过滤——这个原则在GROUPING SETS里更关键。比如你想筛掉销售额< 1000的门店，必须放HAVING，否则“城市小计”会漏掉那些被WHERE提前干掉的门店记录。
另一个坑是ORDER BY：汇总行的排序逻辑和明细不同，建议用GROUPING()值参与排序，比如ORDER BY GROUPING(city), GROUPING(store), city, store，确保总计行排最后、小计行居中。
-
WHERE dept = 'IT'→ 只保留IT部门的明细和IT部门小计，但全表总计仍会计算所有部门 - 真正想限制全表总计范围？得用子查询或CTE先过滤数据源
-
HAVING COUNT(*) > 5对所有分组组合生效，包括()那个空组——空组的COUNT(*)是全表总行数，要留意
GROUPING SETS语法，而是后续怎么让GROUPING()的返回值和业务语义对齐——比如“部门小计”对应GROUPING(dept)=0 AND GROUPING(role)=1，这个组合条件一旦写反，整张表的汇总逻辑就错位了。 
