在sql存储过程中可直接使用递归cte，但需置于select/insert/update语句开头，显式设置option(maxrecursion n)，严格过滤锚点与递归条件防环，并通过临时表复用结果。

在 SQL 存储过程中直接写递归 CTE 是完全可行的，但必须注意语法位置、作用域限制和递归安全边界——否则容易触发 MAXRECURSION 错误或无限循环。

存储过程里写递归CTE的正确位置

递归 CTE 必须作为存储过程主体中某个独立语句的一部分，不能放在变量赋值、IF 分支内部（除非整个分支是完整查询），也不能嵌套在函数调用里。最稳妥的方式是把它放在 SELECT、INSERT 或 UPDATE 语句开头，紧接 WITH 关键字。

• WITH 必须是语句的第一个词；如果前面有注释或 SET，需换行并确保无空格干扰
• 不能把递归 CTE 定义在 DECLARE 后、但未进入实际执行逻辑的位置——它不会被“声明”，只在首次引用时编译
• 若想复用结果，可将递归 CTE 的输出 INSERT INTO #temp，再在后续逻辑中查临时表

递归CTE在存储过程中必须显式设MAXRECURSION

SQL Server 默认递归深度上限是 100 层，而生产环境的组织架构或 BOM 层级常超此限。不加控制时，一旦超过就直接报错：The statement terminated. The maximum recursion 100 has been exhausted before statement completion.

• 必须在最终 SELECT 或 INSERT 语句末尾加 OPTION (MAXRECURSION n)，例如 OPTION (MAXRECURSION 32767)
• MAXRECURSION 0 表示无限制，但极不推荐——失控递归会拖垮会话甚至实例
• 该 OPTION 只对当前语句生效，不能在 CTE 定义里写，也不能跨语句继承

避免父/子ID相同导致的无限循环

这是递归 CTE 最隐蔽也最常踩的坑：当递归成员返回的子节点 ID 和当前父节点 ID 一致（比如数据脏、自关联未过滤、或层级字段为空），就会原地打转。

• 定位点成员（anchor）必须严格筛选出顶层节点，例如 WHERE ManagerID IS NULL 或 Level = 0
• 递归成员中，必须确保 JOIN 条件能推进层级，典型写法是 ON e.ManagerID = cte.EmployeeID，而非反向
• 建议在递归成员里加 WHERE e.EmployeeID != cte.EmployeeID 做兜底防呆（尤其面对不可信源数据）
• 调试时可在递归 CTE 中加入 LEVEL INT 列并用 LEVEL + 1 计数，方便观察是否卡在某一层

CTE不能跨多条语句复用，但可配合临时表解耦

一个常见误解是：定义一次 CTE，后面几个 SELECT 都能用。实际上，CTE 生命周期仅限于紧随其后的那一条语句。

• 如果存储过程需要多次查同一份递归结果（比如先统计人数、再拉明细、再算汇总），必须用 SELECT ... INTO #hierarchy 落到本地临时表
• 不要用表变量 @t 替代——它不支持 SELECT INTO，且无法被后续语句中的 CTE 引用
• 临时表记得加索引（如 CREATE CLUSTERED INDEX IX ON #hierarchy(EmployeeID)），否则深层递归后性能断崖下跌

真正麻烦的不是语法，而是递归路径是否收敛——哪怕 CTE 写得完全合规，只要底层数据存在环状引用（A→B→C→A），MAXRECURSION 就只是延缓报错时间。上线前务必用真实数据做环检测，而不是依赖“理论上没环”。