递归CTE不能直接包含聚合函数，因其执行引擎要求锚点与递归成员列结构严格一致，聚合会破坏可迭代性而报错Msg 467；正确做法是先递归展开树形结构并携带root_id等分组字段，再在外层SELECT中GROUP BY聚合。
递归CTE本身不能直接包含聚合函数（如 SUM()、COUNT()），想在树形结构中做父子汇总，必须把“递归展开”和“聚合统计”拆成两步——这是硬性限制，不是写法问题。
为什么递归CTE里不能直接写GROUP BY或SUM()
SQL Server 的递归 CTE 执行引擎要求：锚点查询和递归成员都必须是集合操作（set-based），且每轮迭代输出的列结构必须严格一致。一旦加入 GROUP BY 或聚合函数，就破坏了行集的可迭代性，直接报错 Msg 467, Level 16（aggregate function not allowed in recursive part）。
- 递归过程本质是“逐层追加结果”，不是“逐层计算指标”
- 你看到的“某部门下属总人数”其实是展开后对所有子孙行按
root_id分组的结果，不是递归内部算出来的 - 强行在递归块里加
SUM(price)，SQL Server 会拒绝编译，不给执行机会
正确做法：先递归展开，再外层聚合
把树展开成扁平关系表，再用常规 GROUP BY 统计。关键在于递归时带出足够用于后续分组的字段，比如 root_id、level、path。
- 锚点查询必须选好起点，并初始化
root_id = id和level = 0 - 递归成员用
UNION ALL连接，继承上层root_id，更新level，避免用UNION（去重会中断递归） - 外层
SELECT必须显式写出字段名，不能用SELECT *，否则 SQL Server 不同版本可能因列序变化导致聚合错位 - 如果要按根节点汇总金额，CTE 中就得提前关联明细表并只保留必要字段，而不是在递归里 JOIN —— 否则中间结果爆炸
示例片段：
WITH org_tree AS ( SELECT id, name, parent_id, id AS root_id, 0 AS level FROM dept WHERE parent_id IS NULL UNION ALL SELECT d.id, d.name, d.parent_id, t.root_id, t.level + 1 FROM dept d INNER JOIN org_tree t ON d.parent_id = t.id ) SELECT root_id, COUNT(*) AS descendant_count, SUM(o.amount) AS total_amount FROM org_tree t LEFT JOIN orders o ON o.dept_id = t.id GROUP BY root_id;
容易被忽略的性能陷阱
递归展开后数据量可能远超预期，尤其当树深但宽、或存在隐式环时，聚合阶段会变慢甚至超时。
- 没加
OPTION (MAXRECURSION n)？默认 100 层就中断，报Msg 530；设为0要小心栈溢出 - 递归结果未去重就聚合？一个叶子节点被多条路径重复包含（如 A→B→C 和 A→D→C），
COUNT(*)就虚高 - JOIN 明细表放在递归内？错误示范：
SELECT ..., i.price FROM dept d JOIN order_items i ...→ 中间结果从千行膨胀到百万行 -
root_id字段类型和关联表不一致？比如 dept.id 是INT，但 order_items.dept_id 是VARCHAR→ 隐式转换导致索引失效
需要聚合条件更新时，别在递归CTE里UPDATE
想把“下属员工数 ≥ 5 的部门状态设为 active”，不能在递归 CTE 里直接 UPDATE。CTE 若含递归或 GROUP BY，就不可更新。
- 必须分两步：先用递归 CTE + 外层聚合算出结果，存进另一个可更新 CTE（只查单表、无聚合、无 DISTINCT）
- 这个可更新 CTE 必须以分号开头：
;+WITH cte AS (...)+UPDATE cte SET ... - CTE 名字不能和基表名相同，否则
UPDATE dept SET ... FROM cte会歧义
真正难的不是写出来，而是判断哪一层该收口、哪一层必须展开——多数人卡在“以为递归能算总数”，其实它只负责“拉出所有相关行”。
