递归查询不能在CTE内部直接GROUP BY，必须先用WITH RECURSIVE展开完整层级，再在外层SELECT中分组；因递归要求每层输出行结构严格一致，而GROUP BY会合并行、破坏迭代基础，导致PostgreSQL报错或MySQL返回空结果。
递归查询本身不直接支持分组统计，必须拆成两步：先用 WITH RECURSIVE 展开完整层级关系，再在外层查询中 GROUP BY。在递归体内部写 GROUP BY 或 SUM() 会报错，这是多数人卡住的第一步。
为什么不能在递归CTE里直接GROUP BY？
数据库语法强制要求递归成员必须能“逐行生成下一层”，而 GROUP BY 会合并多行、破坏行级对应关系，导致递归链断裂。PostgreSQL 报错：recursive query "xxx" does not have the form non-recursive-term UNION [ALL] recursive-term；MySQL 则可能返回空结果或截断。
-
GROUP BY、SUM()、COUNT()、DISTINCT全部禁止出现在递归支（UNION ALL 右侧）中 - 锚点查询（UNION ALL 左侧）里加
GROUP BY也危险——除非你确认该层数据天然独立、不依赖子层 - 真正安全的聚合位置只有一个：递归 CTE 定义完成后的外层
SELECT
怎么让每个父节点统计自己所有子孙的数据？
关键不是“查完再分组”，而是让递归过程携带根节点标识，把树形关系摊平成“祖先 → 后代”映射表，再按祖先字段聚合。比如要统计每个部门下的员工总数：
- 递归 CTE 中必须保留
root_id字段，从锚点开始就设为当前节点 ID，递归时继承不变 - 递归 JOIN 要基于
parent_id = ancestor.id，而不是反过来，否则会漏掉中间层 - 外层
JOIN员工表时，关联字段得是employee.dept_id = tree.descendant_id，不是原始部门 ID - 最后
GROUP BY tree.root_id，才能得到“每个顶层部门及其全部下属部门的员工总和”
示例片段：WITH RECURSIVE dept_tree AS ( SELECT id AS root_id, id AS descendant_id FROM departments UNION ALL SELECT t.root_id, d.id FROM departments d JOIN dept_tree t ON d.parent_id = t.descendant_id ) SELECT t.root_id, COUNT(e.id) FROM dept_tree t LEFT JOIN employees e ON e.dept_id = t.descendant_id GROUP BY t.root_id;
MySQL 8.0+ 分组前必须调这个参数
MySQL 默认递归深度上限是 1000，超过就中断并报错：ERROR 3636 (HY000): Recursive query aborted after 1001 iterations。这个限制无法通过 SQL 语句内声明绕过，必须提前执行 session 级设置：
-
SET SESSION cte_max_recursion_depth = 5000;—— 必须在递归查询前运行，且对当前连接生效 - 如果用连接池，每次获取连接后都得重设，不能只设一次
- 值设太高有内存风险，建议按业务最大树深预估，留 20% 余量
- PostgreSQL 和 SQL Server 没这限制，但也要注意循环引用导致无限递归——确保
parent_id不指向自身或形成环
分组维度选错会导致统计逻辑失效
很多人递归写对了，但最后 GROUP BY 还是按原始表的 id 或 parent_id，结果只是算出每个节点直属下级的数据，完全没体现“向上汇总”的业务含义。
- 按
level分组适合统计“第 N 层有多少节点”，但拿不到某节点的子树总量 - 按
parent_id分组只能拿到直接子节点聚合，漏掉孙子及更深层 - 真正需要的是按递归过程中携带的
root_id或ancestor_id分组，这才是业务意义上的“统计范围边界” - 如果业务要“每个节点展示自己 + 所有后代的总和”，就得在递归体中做累加（锚点取自身值，递归支
SUM(child.sum_value)），这时GROUP BY放在递归支里是合法且必需的——但仅限于按父表字段分组，如p.id
最易被忽略的一点：递归展开后数据量可能指数级膨胀，尤其是多表 JOIN 场景。先跑 SELECT COUNT(*) 确认结果行数，再决定是否加索引或改用闭包表优化。
