grouping_id为每种分组组合生成唯一整数编码，将各列grouping()结果按参数顺序拼成二进制再转十进制，值越小越明细（0为全明细），越大越粗粒度（如三列时7为全局汇总）；必须严格匹配group by中基础列名及顺序，常用于having中精准过滤层级。
GROUPING_ID 不是用来“区分”汇总行的工具，而是给每种汇总组合分配一个唯一整数编码——它本身不输出可读标签，但能让你用数字精准筛选层级。直接在 WHERE 或 HAVING 里用它过滤，比堆 CASE WHEN GROUPING(a)=0 AND GROUPING(b)=1... 清晰得多。
GROUPING_ID 的值怎么算出来的？
它把每个分组列对应的 GROUPING() 结果（0 或 1）按参数顺序拼成二进制位，再转十进制：
— 最低位对应最后一个参数，最高位对应第一个参数（注意这个顺序！）
— 比如 GROUPING_ID(a, b, c)：若 a 被上卷（GROUPING(a)=1）、b 和 c 保留（都为 0），则二进制是 100 → 十进制 4
常见误区：
• 把 SELECT 列表里的别名或表达式传给 GROUPING_ID → 报错
• 参数顺序和 GROUP BY 中实际列顺序不一致 → 编码全错，比如写成 GROUPING_ID(b, a, c) 而 GROUP BY a, b, c
• 误以为值越大越“明细” → 实际相反：0 是最细粒度（全列分组），7（三列时）是全局汇总
怎么用 GROUPING_ID 过滤特定汇总层？
必须用在 HAVING 或 SELECT + 后续逻辑中（不能用在 WHERE，因为汇总行还没生成）：
• 想只保留「按 a 和 b 分组」+「仅按 a 分组」两层，排除全局汇总 → 先确认维度数和顺序，再列出目标值：
- (a,b) → GROUPING(a)=0, GROUPING(b)=0 → 00 → 0
- (a) → GROUPING(a)=0, GROUPING(b)=1 → 01 → 1
- 所以写 HAVING GROUPING_ID(a,b) IN (0,1)
关键限制：
• GROUPING_ID 的参数必须严格匹配 GROUP BY 子句中出现的基础列名（不能是 DATEPART(year, orderdate)，除非 GROUP BY 里也这么写）
• 如果用了 ROLLUP(a,b,c)，那 GROUPING_ID(a,b,c) 合法；换成 GROUPING_ID(a,c) 就漏掉中间列，结果不可靠
• GROUPING_ID(a,b,c) 和 GROUPING_ID(a,c,b) 完全不同——后者最低位对应 b，不是 c
GROUPING_ID 和 GROUPING 一起用的实际场景
单独用 GROUPING_ID 只能筛层级，没法加标签；通常要配合 GROUPING() 做语义化展示：
• 在 SELECT 里用 CASE WHEN GROUPING_ID(a,b) = 0 THEN a ELSE '(All A)' 会出错（a 在汇总行是 NULL，但你没处理）
• 正确做法是结合 GROUPING() 判断来源：
CASE WHEN GROUPING(a) = 1 THEN 'Total' ELSE a END AS a_label
CASE WHEN GROUPING(b) = 1 THEN 'Subtotal' ELSE b END AS b_label
容易踩的坑：
• 在 ORDER BY 里只排业务字段（比如 ORDER BY a, b），会导致汇总行插在明细中间 → 必须把 GROUPING() 结果加进去：ORDER BY a, GROUPING(b), b
• 用 IS NULL 替代 GROUPING() → 会把原始数据里的真实 NULL 和系统生成的占位符混在一起，总数对不上
• 导出到 Excel 后发现小计行不见了 → 很可能是前端过滤逻辑误删了 GROUPING_ID = 1 的行，而没意识到这是合法的部门级汇总
真正难的不是算出 GROUPING_ID 的值，而是确认你的 GROUP BY 子句里到底有几个参与分组的列、它们的物理顺序是什么、以及哪些组合是你报表真正需要的——漏掉一个维度或颠倒顺序，整个编码体系就崩了。
