递归CTE中禁止在锚点或递归成员内使用SUM()、COUNT()等聚合函数，否则因列结构不匹配报错；必须先展开完整层级（含root_id或level字段），再在外层查询按root_id或level分组聚合。
递归CTE里不能直接用SUM()或COUNT()
直接在递归体（anchor 或 recursive member）中写 SUM()、COUNT() 会触发报错 “递归锚点和递归成员列数不匹配”，因为聚合改变了字段数量或类型。SQL Server 要求锚点和递归部分输出的列名、数量、顺序、数据类型必须完全一致。
常见错误写法：SELECT id, name, parent_id, SUM(sales) FROM ... 放在 anchor 或 UNION ALL 后面——这会让两部分结构对不上。
正确路径只有一条：递归 CTE 只负责展开层级关系（比如把 A→B→C 和 A→D→C 都拉平），所有聚合必须挪到最外层查询做。
先展开，再分组：父子汇总必须加 root_id 或 path 字段
如果目标是“每个部门及其全部下属员工的总薪资”，光靠 WITH RECURSIVE org AS (...) 拉出树形结果还不够。默认展开后，一个叶子节点可能被多个父路径重复包含（比如 C 同时属于 A→B→C 和 A→D→C），直接 GROUP BY dept_id 会导致数值翻倍。
关键是在递归 CTE 里带出可追溯的根标识：
- 用
id AS root_id在 anchor 中初始化，递归部分保持t.root_id传递 - 或构造路径数组（SQL Server 不原生支持 ARRAY，可用
CONCAT(t.path, '>', c.id)模拟） - 这样外层才能按
root_id分组，确保每个节点只被其直属根节点统计一次
中间结果膨胀比性能更危险：别在CTE里JOIN明细表
很多人以为“用了 CTE 就算优化了”，结果把千万行订单明细和用户表在 CTE 里 JOIN，再 GROUP BY，中间集还是上千万行——CTE 不减少数据量，只是让逻辑可读。
真正有效的预聚合要满足两个条件：
- 聚合动作发生在递归 CTE 内部，且仅基于单表或已收敛的关联结果（如先
SELECT order_id, SUM(price) FROM order_items GROUP BY order_id） - 递归 CTE 的输入源本身已做过裁剪（例如只取 status = 'shipped' 的订单，而非全量 orders 表）
否则，外层再怎么 GROUP BY u.city，都得扛着膨胀后的中间集跑。
递归深度失控前必须加 OPTION (MAXRECURSION n)
SQL Server 默认递归上限是 100 层，超限直接报错 Msg 530，且不会返回任何结果。线上组织树或分类树深度常超预期，尤其当存在脏数据（如循环引用：A→B→C→A）时，不设限等于服务不可用。
安全做法：
- 明确业务最大深度（如公司最多 8 级汇报线），设
OPTION (MAXRECURSION 8) - 不确定时用
OPTION (MAXRECURSION 0)，但必须配合前置校验（如WHERE parent_id != id防自环） - 永远不要依赖默认值——它既不显式，也不符合实际场景
递归 CTE 的性能瓶颈往往不在 CPU，而在中间结果集大小和内存驻留时间；一旦漏掉 OPTION 或放任无约束展开，轻则超时，重则阻塞 tempdb。
