grouping sets可在单查询中同时产出明细与多级汇总行，避免重复扫描；需用grouping()函数区分占位null与真实null，sql server、postgresql、oracle支持，mysql不支持。
用 GROUPING SETS 实现汇总+明细一锅端
直接上结论：SQL Server、PostgreSQL（14+）、Oracle 都支持 GROUPING SETS，它能在一个查询里同时产出分组聚合行和原始明细行，无需 UNION 或子查询拼接，语义清晰且执行计划更优。
常见错误是硬套 GROUP BY + UNION ALL：既要查每个部门的平均工资，又要查所有人明细，结果写两遍表、两次扫描，还容易漏掉 NULL 标识哪行是汇总。
正确做法是把明细视作“按所有列分组”的一种情况，再和真正的分组组合起来：
SELECT dept, name, salary, AVG(salary) OVER (PARTITION BY dept) AS avg_dept_salary, GROUPING(dept) AS is_dept_agg, GROUPING(name) AS is_name_agg FROM employees GROUP BY GROUPING SETS ((dept, name), (dept), ())
其中 (dept, name) 是明细（每行独立一组），(dept) 是部门汇总，() 是全表总计；GROUPING() 函数返回 1 表示该列值是系统填充的 NULL（用于标识汇总行），不是原始数据里的空值。
MySQL 用户别硬扛，用 WITH ROLLUP + 条件过滤
MySQL 不支持 GROUPING SETS，但 WITH ROLLUP 能生成层级汇总行，配合 GROUPING()（8.0.12+）或手动判 IS NULL 可区分层级。问题是它强制按 GROUP BY 列顺序做树状汇总，不能跳级或并列输出明细。
实用解法是把明细“伪装”成一个虚拟分组维度，再用 UNION ALL 拼接——但只拼一次、只扫一次表：
- 先用 CTE 或派生表把原始数据加一列
grp_type = 'detail' - 再对分组数据加
grp_type = 'summary' - 最后
UNION ALL并统一排序（比如ORDER BY grp_type DESC, dept, name）
比反复查表强，也比在应用层合并更可控。注意：WITH ROLLUP 的 NULL 和真实 NULL 无法区分，必须依赖额外标记列。
窗口函数能替代部分场景，但不能取代分组行
如果只是想“在每行旁边显示部门平均值”，用 AVG(salary) OVER (PARTITION BY dept) 就够了，性能好、逻辑直白。但它不产生新行——你得不到单独一行“销售部：平均 15000”这样的汇总记录。
所以得看需求本质：
- 需要**附加统计值** → 选窗口函数
- 需要**新增汇总行**（报表里常要求“小计/合计插入到明细中间”）→ 必须用 GROUPING SETS 或模拟方案
- 混合需求（明细带统计 + 单独汇总行）→ 两者结合，但注意字段对齐，比如汇总行的 name 得填 '(合计)' 而非 NULL，否则前端渲染容易错位。
ORDER BY 和 NULL 处理最容易翻车
多个分组集合并后，排序逻辑会变复杂。数据库不会自动把明细排前面、汇总排后面——你得显式控制：
- 用
GROUPING()值排序：ORDER BY GROUPING(dept), dept, GROUPING(name), name - 避免直接
ORDER BY dept, name，否则汇总行（dept='HR',name=NULL）可能插在明细中间 - 导出到 Excel 或报表工具时，
NULL显示为空格还是“(空)”取决于客户端，建议在 SQL 层用COALESCE(name, '(小计)')显式赋值
真正麻烦的是跨数据库兼容：PostgreSQL 的 GROUPING() 行为和 SQL Server 一致，但旧版 MySQL 没这函数，Oracle 对空字符串和 NULL 的分组处理也有差异。只要涉及多库适配，汇总行的标识逻辑就得收口到应用层判断。
