GROUPING SETS 在 PostgreSQL 中是逻辑合并工具而非性能加速器，它通过一次扫描替代多个 GROUP BY 查询，但实际执行仍为每组独立聚合；是否提速取决于原始写法、数据量、索引匹配度及元组设计合理性。
GROUPING SETS 在 PostgreSQL 中不是性能“加速器”，而是逻辑合并工具——它把多个 GROUP BY 查询压缩成一次扫描，避免重复读表，但实际执行仍按你写的每组分组独立聚合。是否提速，取决于你原本怎么写、数据量多大、索引是否匹配。
GROUPING SETS 语法必须写对，否则直接报错
常见错误是漏掉外层括号或元组括号：GROUPING SETS (region, product) ❌，必须写成 GROUPING SETS ((region), (product), (region, product)) ✅。() 表示全表总计，不能省略括号，也不能写成 GROUPING SETS ()（语法错误）。PostgreSQL 9.5+ 支持，但低于该版本会提示 ERROR: syntax error at or near "GROUPING"。
必须配合 GROUPING() 函数，否则 NULL 分不清真假
比如你查 sales 表，用 GROUPING SETS ((dept), (region))，结果里 dept 列为 NULL 的行，可能是：真实数据中部门就是 NULL；也可能是按 region 分组时 dept 被折叠出来的占位符。只靠 dept IS NULL 判断会误杀。
-
GROUPING(dept) = 1 AND GROUPING(region) = 0→ 这行是按region分的，dept是占位NULL -
GROUPING(dept) = 0 AND GROUPING(region) = 1→ 这行是按dept分的，region是占位NULL -
GROUPING(dept) = 1 AND GROUPING(region) = 1→ 不可能出现在这个例子中（因为没写()），但如果加了就表示全表总计
别在 SELECT 里直接 COALESCE(dept, 'All') ——原始 dept 真为 NULL 时会被覆盖。正确写法是：CASE WHEN GROUPING(dept) = 1 THEN 'All' ELSE dept END。
索引要覆盖最宽的分组组合，否则照样慢
PostgreSQL 优化器通常会选择能覆盖最大元组的索引。例如你写 GROUPING SETS ((a), (b), (a,b,c))，它大概率会走 (a,b,c) 复合索引，再从里面“提取”出前两组。但如果只有 (a) 和 (b) 单列索引，引擎可能退化为多次顺序扫描。
- 优先建
CREATE INDEX ON sales (region, product_line, year);（如果最细粒度是三字段） - 避免只建
(year, region)却在GROUPING SETS里用(region, year)——字段顺序不一致时，B-tree 索引可能无法高效利用 - 用
EXPLAIN (ANALYZE, BUFFERS)看执行计划，确认是否出现多个GroupAggregate或HashAggregate节点；若看到多次Seq Scan，说明索引没生效或没建对
别和 WHERE 条件硬拼，容易漏掉汇总行
WHERE 是在聚合前过滤的。如果你写 WHERE dept IS NOT NULL，那所有按 region 分组的行（此时 dept 是 NULL 占位）都会被提前干掉，只剩按 dept 分的那部分——汇总逻辑就断了。
- 需要过滤原始数据？把条件下推到子查询或 CTE 中，例如：
WITH filtered AS (SELECT * FROM sales WHERE status = 'active')，再对filtered做GROUPING SETS - 需要按汇总层级筛选？用
HAVING（作用于聚合后）或外层WHERE套GROUPING()判断，例如：WHERE GROUPING(dept) = 1筛出所有不含dept的行
真正容易被忽略的点是：GROUPING SETS 不改变底层聚合语义，它只是帮你少写几遍 SELECT ... GROUP BY。如果你的原始数据本身没索引、字段基数高、或者写了太多冗余元组（比如 ((a),(a,b),(a,b,c),(a,b,c,d))），性能反而比单个 GROUP BY 更差——因为 PostgreSQL 仍得为每组做一次哈希分组。
