递归CTE中GROUP BY报错是因为锚点与递归成员列数、类型、顺序必须严格一致，禁止在递归体内使用聚合函数或增删字段；聚合操作须置于最外层查询。
递归CTE查出完整树形结构后，为什么GROUP BY会报错“递归锚点和递归成员列数不匹配”
因为递归CTE的锚点（anchor）和递归成员（recursive member）必须严格保持列名、数量、类型一致。一旦在锚点里写了 SELECT id, name, parent_id, 1 as level，递归部分就不能擅自加聚合字段，比如 SUM(sales)——这会让两部分列数/类型对不上，直接报错。
正确做法是：先用递归CTE把整棵树（含所有子孙）拉平成“节点→后代映射”关系，再在外面套一层普通 GROUP BY 做聚合。不要试图在递归体内部做聚合。
- 锚点只选原始表字段 + 初始层级（如
level = 1），不加任何聚合 - 递归成员只做
JOIN+level + 1，字段顺序和类型必须与锚点完全一致 - 聚合操作一律放在最外层查询，作用于递归结果集
如何用递归CTE生成“每个父节点及其所有直接/间接子节点”的关联列表
核心是构造一个“自连接式展开”：让每个节点都带上它能到达的所有后代（包括自己）。关键在于递归成员中用 ON t.parent_id = c.id（不是 t.id = c.parent_id），这样才能从上往下遍历。
WITH RECURSIVE tree AS ( -- 锚点：所有顶层节点（parent_id IS NULL 或 0） SELECT id, name, parent_id, id as root_id, 0 as depth FROM orgs WHERE parent_id IS NULL <p>UNION ALL</p><p>-- 递归：找所有以当前节点为 parent_id 的子节点，并继承 root_id SELECT c.id, c.name, c.parent_id, t.root_id, t.depth + 1 FROM orgs c INNER JOIN tree t ON c.parent_id = t.id ) SELECT * FROM tree;
这里 root_id 是关键——它把每个子孙都标记回其原始根节点，后续按 root_id 分组就能汇总整个子树。
父子汇总时，SUM() / COUNT() 结果比预期大很多，是不是重复计算了
极大概率是。递归CTE展开后，一个叶子节点可能被多个父路径多次包含（比如 A→B→C 和 A→D→C，C 被算两次）。如果业务只要“以某节点为根的全部下属”，就必须去重或限定路径唯一性。
- 用
DISTINCT ON (root_id, id)（PostgreSQL）或ROW_NUMBER() OVER (PARTITION BY root_id, id ORDER BY depth)去重 - 更稳妥的是在递归前先确保数据无环；否则加
MAXRECURSION（SQL Server）或SEARCH DEPTH FIRST（PostgreSQL）防无限循环 - 若只需统计“直属下级+下级的下级…但不跨分支”，确认递归条件没写反（常见错误：
ON t.id = c.parent_id会导致向上查祖先，而非向下查子孙）
MySQL 8.0+ 和 SQL Server 中递归CTE聚合的语法差异点
MySQL 要求递归部分必须显式写出所有字段，且不能有子查询或窗口函数；SQL Server 允许在递归成员里用简单表达式，但禁止聚合函数。两者都不支持在递归定义内用 GROUP BY 或 HAVING。
- MySQL：锚点和递归部分字段列表必须字面一致，连别名都要一样；
UNION ALL后不能跟ORDER BY，排序得放外层 - SQL Server：需在
OPTION (MAXRECURSION n)控制深度，否则默认只跑 100 层；聚合时外层GROUP BY必须包含所有非聚合列，包括root_id、name等 - 共性陷阱：所有数据库中，递归CTE定义后不能直接接
GROUP BY，必须用括号包裹或起别名再查
真正麻烦的不是写法，而是当树深超过 50 层、节点数超 10 万时，递归展开本身就会变慢——这时候该考虑预计算路径编码（如 lft/rgt）或物化路径（path = '/1/5/23/'）了。
