GROUPING SETS 是手动枚举分组组合的语法，非智能优化器；它逐组执行并 UNION ALL 结果，不自动复用计算，需配合 GROUPING() 区分占位 NULL 与真实 NULL，并依赖覆盖最宽组合的复合索引。
GROUPING SETS 本质是手动枚举分组组合，不是自动推导
很多人误以为 GROUPING SETS 是某种智能聚合优化器，其实它只是显式列出你想要的每一组 GROUP BY 组合。数据库不会帮你合并、剪枝或跳过重复计算——你写几组，它就执行几组，最后再把结果堆叠（UNION ALL 语义）。所以性能瓶颈往往来自冗余扫描：比如 GROUPING SETS ((a), (b), (a,b)) 中，(a,b) 的扫描结果无法复用到 (a) 或 (b) 上，除非引擎支持高级物化（如 PostgreSQL 14+ 的哈希复用，但不可依赖）。
实操建议：
- 先用
EXPLAIN看执行计划，确认是否多次全表/索引扫描；若出现多个GroupAggregate或HashAggregate节点，大概率在重复读数据 - 如果维度少（≤3）、组合明确（如只想要「按部门」「按年份」「按部门+年份」），
GROUPING SETS清晰且可控；维度多时（如 5 个字段要全排列），立刻放弃，改用多次查询 + 应用层合并 - 避免嵌套
GROUPING SETS或混用CUBE/ROLLUP，语义易混淆，且各数据库对混合行为的支持不一致（SQL Server 允许，MySQL 8.0 不支持GROUPING SETS本身）
GROUPING() 函数才是识别空值来源的关键
当使用 GROUPING SETS 时，缺失维度的列会显示为 NULL，但这和原始数据里的 NULL 完全无法区分——直接 WHERE col IS NULL 会错杀真实数据。必须用 GROUPING(col) 判断：返回 1 表示该列在此行属于“被折叠的维度”，即人为聚合导致的占位 NULL；返回 0 才是原始数据的 NULL。
常见错误现象：报表里「总计行」的部门名显示为 NULL，但筛选时又把真实部门为 NULL 的记录也过滤掉了。
实操建议：
- 所有涉及
GROUPING SETS的查询，只要 SELECT 列包含可能被折叠的字段，就必须配套用GROUPING()做逻辑判断，例如：COALESCE(dept_name, '总计') AS dept_label是错的；应写成CASE WHEN GROUPING(dept_name) = 1 THEN '总计' ELSE dept_name END AS dept_label -
GROUPING()只接受单列，不能写GROUPING((a,b))；多列判断需分别调用，如GROUPING(a) + GROUPING(b) = 2表示 a 和 b 都被折叠 - PostgreSQL 和 SQL Server 支持
GROUPING_ID()返回位掩码整数，适合复杂组合判断；但 MySQL 不支持，别踩坑
索引设计必须覆盖最宽的分组组合
GROUPING SETS ((a), (b), (a,b,c)) 这类混合粒度查询，优化器通常会选择扫描能覆盖最大组合的索引（如 (a,b,c)），再从该索引中“截取”出 (a) 和 (b) 的分组——前提是索引顺序匹配。如果只建了 (a) 和 (b) 单列索引，数据库大概率放弃索引，回退到全表扫描。
实操建议：
- 优先创建复合索引，字段顺序按最宽分组组合定义，例如：若常用
((region, product), (region), (product))，则建INDEX idx_region_product ON sales(region, product)；不要拆成两个单列索引 - 避免在分组字段上用函数或表达式（如
GROUPING SETS ((YEAR(order_date)), (status))），这会让索引失效；预计算好派生列并建索引更可靠 - 统计信息必须最新：
ANALYZE（PostgreSQL）或UPDATE STATISTICS（SQL Server）后，优化器才更可能选对索引路径
替代方案比硬刚 GROUPING SETS 更实用的场景
当遇到以下情况，强行用 GROUPING SETS 反而增加维护成本和出错概率：
- 需要对不同分组应用不同聚合逻辑（如「按部门」求平均薪资，「按年份」求累计薪资，「部门+年份」求标准差）——此时 UNION ALL 显式拼接更清晰
- 分组维度来自参数化输入（如前端勾选任意 1–4 个字段），动态拼 SQL 比写死
GROUPING SETS组合更灵活 - 数据量大且部分分组结果极少被访问（如「按城市+门店+班次」只用于后台调试），预计算物化视图或汇总表比每次实时聚合更稳
真正容易被忽略的是：GROUPING SETS 的语法糖价值，远不如它暴露的问题本身——你是否真的需要所有组合？还是只是没想清楚业务指标的最小完备集？先砍掉 30% 的分组需求，比调优一条 200 行的 GROUPING SETS 查询更有效。
