GROUPING()是识别ROLLUP汇总行的唯一可靠方法，对自动生成的分组字段返回1、明细行返回0，必须用于GROUP BY中ROLLUP的列，常配合CASE WHEN美化显示并纳入ORDER BY确保排序逻辑正确。
ROLLUP 生成分类汇总时，GROUPING() 怎么识别汇总行
ROLLUP 产生的汇总行不是真实数据，SQL 无法靠 NULL 值准确区分“本就是空的明细”和“人为生成的汇总”。GROUPING() 是唯一可靠方式：它对由 ROLLUP 自动生成的分组字段返回 1，对真实明细行返回 0。
常见错误是直接用 IS NULL 判断——比如 region IS NULL 可能误判真实为 NULL 的地区记录；而 GROUPING(region) = 1 才真正表示“这行是 region 维度上的汇总”。
-
GROUPING()必须作用于GROUP BY中参与 ROLLUP 的列，否则报错 - 多列 ROLLUP（如
GROUP BY ROLLUP(a, b, c)）中，GROUPING(a)、GROUPING(b)、GROUPING(c)各自独立返回0或1 - 常配合
CASE WHEN修饰显示字段，例如：CASE WHEN GROUPING(region) = 1 THEN '总计' ELSE region END AS region_label
ROLLUP 和 GROUPING SETS 在明细+汇总场景下怎么选
如果只要“按部门 + 按部门+年份 + 全局总计”三级汇总，ROLLUP(dept, year) 最简洁；但如果需要“按部门汇总”和“按年份汇总”两个平级汇总（不包含部门×年份交叉），就得用 GROUPING SETS，因为 ROLLUP 会强制生成中间层级。
典型陷阱：误以为 ROLLUP(a, b) 等价于 GROUPING SETS((a), (b), ()) —— 实际上前者产生 (a,b)、(a)、() 三组，后者缺了最细粒度的 (a,b) 明细，也漏了 (a,b) 这一层汇总。
- 要保留原始明细行 + 多级汇总 → 用
ROLLUP，再用GROUPING()标记层级 - 只要若干指定组合的汇总（不含中间层或不含明细）→ 用
GROUPING SETS - MySQL 8.0+ 支持 ROLLUP，但不支持
GROUPING()函数（需改用COALESCE()+ 逻辑推断，可靠性下降）
带排序的 ROLLUP 结果为什么总乱序
ROLLUP 不保证输出顺序，即使 ORDER BY 写在最后，数据库也可能先做分组再排序，导致“部门A明细→部门A汇总→部门B明细→总计”这种交错结构被拆散。真正可控的方式是把 GROUPING() 结果纳入排序键。
例如想让汇总行始终出现在对应明细下方，且“总计”在最末：按 dept 升序、再按 GROUPING(year) 升序、再按 year 升序排，就能让 (dept, year) 行（GROUPING(year)=0）在前，(dept) 行（GROUPING(year)=1）紧随其后。
- 避免只写
ORDER BY dept, year—— 汇总行的year是NULL，会被排到最前或最后，脱离上下文 - PostgreSQL 和 SQL Server 对
GROUPING()排序支持良好；Oracle 需注意GROUPING()返回的是NUMBER，排序无问题 - 若用窗口函数叠加 ROLLUP，必须明确
PARTITION BY不含 ROLLUP 生成的虚拟分组，否则出错
ROLLUP 性能差得离谱？这些地方最容易拖慢
ROLLUP 本质是多次分组聚合再合并，数据量稍大就容易触发临时表、磁盘排序甚至内存溢出。性能瓶颈往往不出在语法本身，而在隐式转换和缺失统计信息。
- 参与 ROLLUP 的字段如果有函数包装（如
UPPER(dept)），会导致索引失效，全表扫描不可避免 - 字符串字段未建统计信息（如 PostgreSQL 的
ANALYZE未运行），优化器可能低估分组数，分配过少内存 - 在 WHERE 条件里过滤 ROLLUP 字段（如
WHERE region = '华东'）不会提前剪枝——ROLLUP 仍会算出所有分组，再过滤，应尽量前置过滤 - 替代方案：明细查一次、各维度汇总分别查（用 UNION ALL 合并），有时比单条 ROLLUP 更快，尤其当只需部分汇总层级时
GROUPING() 不是装饰函数，它是解开 ROLLUP 黑箱的钥匙；没它，你就只能靠猜哪行是汇总——而生产环境里，猜错一行，报表就错一片。
