GROUP BY本身不处理父子层级，必须先用CONNECT BY或递归CTE展平树结构，再按root_id等逻辑键分组聚合；直接GROUP BY parent_id, id仅做扁平分组，无法获取子树总和。
GROUP BY 本身不处理父子层级，必须先展平再分组
直接写 GROUP BY parent_id, id 只会按物理字段分组，完全得不到“某父节点下所有子孙数据的总和”。因为原始表里每行只存一个节点及其直系父节点，没有路径信息，GROUP BY 无法跨行感知上下级关系。真正要聚合整棵子树，必须先把树结构拉成扁平列表——让每个叶子节点带上它所有祖先的 ID（或名称），再按根节点分组。
- Oracle 必须用
CONNECT BY+CONNECT_BY_ROOT，且CONNECT_BY_ROOT dept_id要同时出现在SELECT和GROUP BY中，不能加别名后引用 - PostgreSQL / SQL Server / MySQL 8.0+ 推荐用递归 CTE：锚点选
parent_id IS NULL的顶层节点，递归部分JOIN自身，并拼接path或记录level - 过滤条件（如员工状态）不能写在
CONNECT BY或递归 CTE 内部，否则会剪枝；应移到外层查询
递归 CTE 构建路径后，GROUP BY 才有意义
递归展开不是目的，而是为 GROUP BY 提供可分组的逻辑键。比如你想统计“每个部门及其全部下属部门的总销售额”，那外层 GROUP BY 的目标字段，必须是递归结果中代表“顶层归属”的字段，例如 root_dept_id 或 path[1]。
- PostgreSQL 示例中，递归后得到每行的
path（如{1,3,7}），可用path[1]提取根 ID，再GROUP BY path[1] - SQL Server 需加
OPTION (MAXRECURSION n)，否则默认只跑 100 层，深层组织架构会截断 - MySQL 8.0+ 递归 CTE 语法一致，但不支持
array类型，得用字符串拼接CONCAT(path, ',', id)，后续解析更麻烦
ROLLUP 和 CUBE 不能替代层级聚合
GROUP BY region, dept WITH ROLLUP 看似有层级感，但它只是按字段顺序生成 (r,d)、(r,NULL)、(NULL,NULL) 这类占位行，不包含任何父子语义。它不会把“华东区-销售部”的数据自动累加进“华东区”汇总行——因为那行数据本来就在。真正的父子聚合，依赖的是数据行本身的路径归属，而不是 NULL 占位。
- 误用 ROLLUP 当树形菜单渲染，会导致“华东”和“华东-销售部”并列，且无法区分哪行是真实部门、哪行是系统填充
-
GROUPING()函数只能识别“这行是不是 ROLLUP 填的 NULL”，不能告诉你“这个 NULL 对应哪棵子树” - 若真需要动态层级报表（如用户点开某部门才加载其子部门汇总），必须靠应用层控制递归深度或预生成路径表，不能靠 ROLLUP 推导
容易被忽略的关键点：聚合字段必须来自展平后的逻辑视图
很多人在递归 CTE 外层写 SUM(sales)，却把 sales 字段从原始事实表直接 JOIN 进来，忘了检查关联逻辑是否对齐路径。一旦 JOIN 条件没绑定到递归结果中的节点 ID，聚合就会错位或重复计数。
- 确保事实表（如 sales）是通过递归结果中的
node_id或employee_id关联，而不是原始表的dept_id - 如果一个员工属于多个部门（如矩阵架构），需明确聚合口径：是按汇报线？还是按预算归属？路径构造时就得定死规则
- 性能上，递归 CTE + JOIN 比纯 CONNECT BY 更可控，尤其当需要多张维度表参与时；但深度超 20 层时，务必加
LIMIT或预设最大深度
