ROLLUP必须按业务层级从左到右书写，如部门→小组→员工需写GROUP BY dept, team, emp WITH ROLLUP；顺序错误则归并路径错乱，导致中间层小计缺失，仅生成无业务意义的空汇总行。
ROLLUP 必须按业务层级从左到右写，顺序错就汇总错
ROLLUP 不是“自动识别父子关系”，它只认 GROUP BY 列的书写顺序。比如你要算「部门 → 小组 → 员工」三级小计，必须写 GROUP BY dept, team, emp WITH ROLLUP；如果写成 GROUP BY emp, team, dept，结果里根本不会出现“每个小组的总和”，只会出员工级、空团队、空部门三层——因为 ROLLUP 只沿主路径向上归并：(emp,team,dept) → (emp,team,NULL) → (emp,NULL,NULL) → (NULL,NULL,NULL)。
- 常见错误：把高粒度字段（如
product_id）放在前面，导致顶层小计变成“所有商品总和”，中间层（如品类、品牌）直接消失 - 正确做法：按业务逻辑由粗到细排列，例如时间维度用
year, quarter, month，组织架构用region, dept, team - MySQL 8.0+ 和 SQL Server 支持
WITH ROLLUP，PostgreSQL 需用GROUPING SETS模拟
CUBE 适合交叉分析，但 4 个字段就生成 16 行结果
CUBE 会穷举所有列组合（2ⁿ 种），不是“多几个 NULL”那么简单。比如 GROUP BY CUBE(a, b, c, d) 直接产出 16 行分组结果，其中包含大量无业务意义的组合，例如 (NULL, b, NULL, d) 或 (a, NULL, c, NULL) —— 这些在报表里往往要过滤掉，否则用户看不懂，数据库也白算。
- 适用场景：明确需要任意切片钻取，比如“选中某产品线后看各地区销量”，或“固定年份查月度+渠道组合”
- 慎用场景：纯树状层级（如省→市→区）、字段超过 3 个、数据量大且对响应时间敏感
- 必须搭配
GROUPING()：仅靠IS NULL无法区分真实空值和 CUBE 占位符，GROUPING(a)返回 1 才表示该行是 a 维度的汇总行
递归 CTE 汇总必须在递归支内聚合，不能丢到外面 GROUP BY
想统计组织树中每个节点下的全部子节点销售额，不能先递归出完整树再 GROUP BY parent_id —— 这会导致 PostgreSQL 报错 recursive query does not have the form non-recursive-term UNION ALL recursive-term，MySQL 可能返回空或截断。递归 CTE 的聚合逻辑必须嵌入递归支内部。
- 锚点（非递归部分）只取叶子节点或基础明细，不加
GROUP BY - 递归支里用
JOIN关联上一层结果，并对子节点求和：COALESCE(SUM(c.sum_value), 0)，再GROUP BY p.id, p.parent_id - 深度超限要处理：PostgreSQL 默认 100 层，SQL Server 用
OPTION (MAXRECURSION 0)，MySQL 8.0 可调cte_max_recursion_depth
GROUPING SETS 是最可控的方案，但写法容易漏括号
当你只需要特定几层汇总（比如只要“部门小计”和“总计”，不要员工明细），GROUPING SETS 比 ROLLUP 更干净。但它语法严格：每个分组必须用括号包裹，空组用 ()，少一个括号或逗号就会报错。
- 正确写法：
GROUP BY GROUPING SETS ((dept, emp), (dept), ()) - 错误写法：
GROUP BY GROUPING SETS (dept, emp), (dept), ()（缺外层括号）或((dept, emp), (dept), )（末尾多逗号） - 优势：结果行数确定、无冗余组合、兼容性好（MySQL 8.0+/PostgreSQL/SQL Server 都支持）
- 注意：窗口函数不能直接作用于
GROUPING SETS结果，需先用 CTE 或子查询封装再开窗
实际用哪种，取决于你手里的数据结构是否真有父子层级、要不要支持任意维度切换、以及 DBA 是否允许开递归或调深限制——这些细节不确认清楚，光套语法很容易跑出错数据。
