如何在SQL中对父子结构数据执行递归后的分组统计？

递归CTE中禁止在递归成员内使用GROUP BY或SUM()等聚合函数，否则报错；正确做法是先用递归拉平树结构并传递root_id，再在外层SELECT中分组聚合。

递归CTE里不能直接GROUP BY或SUM()

因为递归体（UNION ALL 后面那部分）里禁止出现聚合函数，否则会报错 ERROR: aggregate functions are not allowed in a recursive query's recursive term。锚点和递归成员的列数、类型、顺序必须完全一致，加个 SUM(sales) 就立刻破坏一致性，数据库直接拒绝执行。

常见错误写法是试图在递归内部统计子树总和，比如：

WITH RECURSIVE tree AS (  SELECT id, name, parent_id, sales FROM orgs WHERE parent_id IS NULL  UNION ALL  SELECT c.id, c.name, c.parent_id, SUM(c.sales)  -- ❌ 这里报错  FROM orgs c JOIN tree t ON c.parent_id = t.id)

正确路径只有一条：先用递归把整棵树“拉平”，再在外层查完之后做分组。

• 锚点只选原始字段 + 初始 level 或 root_id，不加任何计算
• 递归成员只做 JOIN + level + 1 或 root_id 传递，字段顺序与锚点严格对齐
• 所有 COUNT()、SUM()、AVG() 都放在最外层 SELECT 里，作用于整个递归结果集

按父节点汇总全部子孙数据，必须带 root_id

如果目标是“每个部门的总人数”或“每个分类下的商品总销量”，光靠 parent_id 不够——它只能连直接下级。你需要让每个子孙都记住自己属于哪个顶层根节点，也就是打上 root_id 标签。

关键在递归成员里用 t.root_id 而不是 c.id：

WITH RECURSIVE tree AS (  -- 锚点：根节点的 root_id 就是自己  SELECT id, name, parent_id, id AS root_id, 0 AS depth  FROM orgs WHERE parent_id IS NULL  UNION ALL  -- 递归：子节点继承父节点的 root_id  SELECT c.id, c.name, c.parent_id, t.root_id, t.depth + 1  FROM orgs c JOIN tree t ON c.parent_id = t.id)SELECT root_id, COUNT(*) AS descendant_count, SUM(sales) AS total_salesFROM treeGROUP BY root_id;

漏掉 root_id 会导致你只能按当前层级或直接父级分组，永远拿不到“以某节点为根的完整子树”数据。

MySQL 5.7 或旧版 PostgreSQL 怎么办？用路径字符串模拟

如果数据库不支持 WITH RECURSIVE（如 MySQL 5.7），而表里又有 path 字段（值如 /1/5/12/），就改用 LIKE 前缀匹配：

统计每个节点及其所有子孙（含自己）：

SELECT c1.id, c1.name, COUNT(c2.id) AS total_descendantsFROM categories c1LEFT JOIN categories c2 ON c2.path LIKE CONCAT(c1.path, '%')GROUP BY c1.id, c1.name;

注意三个易错点：

• 必须用 LEFT JOIN，否则无子节点的根节点会消失
• 路径结尾要统一加斜杠（/1/5/），否则 /1/5% 会误命中 /1/50/
• 若只要“严格子节点”（不含自己），加条件 AND c2.path != c1.path

结果重复、数值翻倍？大概率是数据有环或路径不唯一

递归展开后，一个叶子节点被多次计入不同父路径（比如 A→B→C 和 A→D→C），COUNT() 就会虚高。这不是语法问题，是数据本身有问题。

先检查是否存在环：

• PostgreSQL 可加路径数组防重：用 ARRAY[t.id] AS path，递归时加 WHERE NOT c.id = ANY(t.path)
• SQL Server 加 OPTION (MAXRECURSION 100) 防死循环
• MySQL 8.0 设置 SET SESSION cte_max_recursion_depth = 200

更根本的解法是清理数据：确保 parent_id 不指向自身，且不存在 A→B→A 这类闭环。没这一步，再漂亮的 SQL 也统计不准。