如何实现SQL存储过程的递归调用_通过MAXRECURSION选项控制递归深度-SQL-PHP中文网

MAXRECURSION对递归存储过程无效，仅适用于递归CTE；其深度控制必须依赖@@NESTLEVEL、计数器参数或逻辑终止条件，否则易引发栈溢出或死锁。

如何实现sql存储过程的递归调用_通过maxrecursion选项控制递归深度

SQL Server 中递归存储过程必须显式控制终止，`MAXRECURSION` 不起作用

直接说结论：MAXRECURSION 是 OPTION 查询提示，只对 CTE（尤其是递归 CTE）生效，对存储过程的 EXEC 递归调用完全无效。试图在 EXEC @proc_name 后加 OPTION (MAXRECURSION 10) 会报错，因为语法不合法。

递归存储过程的深度控制只能靠逻辑实现——比如传入计数器参数、检查当前嵌套层级、或依赖 @@NESTLEVEL。

@@NESTLEVEL 返回当前执行环境的嵌套深度（初始为 1，每次 EXEC 存储过程 +1）
超出阈值时应主动 RETURN 或抛出错误，避免无限递归导致栈溢出或超时
注意：触发器、函数、动态 SQL 中的 EXEC 也会计入该值，需预留余量

用 `@@NESTLEVEL` 实现安全递归调用的典型写法

以下是一个带深度防护的树形结构遍历示例，模拟“查找某节点所有子节点”：

CREATE PROCEDURE usp_GetChildNodes
    @ParentID INT,
    @MaxDepth INT = 5
AS
BEGIN
    -- 检查当前嵌套层级是否超限
    IF @@NESTLEVEL > @MaxDepth
    BEGIN
        RAISERROR('Recursion depth exceeded: current level = %d, max = %d', 
                  16, 1, @@NESTLEVEL, @MaxDepth);
        RETURN;
    END
<pre class="brush:php;toolbar:false;">-- 查询直接子节点
SELECT ID, Name FROM Categories WHERE ParentID = @ParentID;

-- 递归调用自身，处理每个子节点
DECLARE @ChildID INT;
DECLARE cur CURSOR LOCAL FOR 
    SELECT ID FROM Categories WHERE ParentID = @ParentID;

OPEN cur;
FETCH NEXT FROM cur INTO @ChildID;
WHILE @@FETCH_STATUS = 0
BEGIN
    EXEC usp_GetChildNodes @ChildID, @MaxDepth; -- 传入相同 MaxDepth
    FETCH NEXT FROM cur INTO @ChildID;
END
CLOSE cur;
DEALLOCATE cur;

END

关键点：

把 @MaxDepth 作为参数传递，比硬编码更灵活，也便于测试不同深度
必须在递归调用前做 @@NESTLEVEL 判断，否则可能在进入下一层后才触发终止，已造成资源浪费
游标不是必须的——如果能用 WHILE + TOP 1 拉取，或改用临时表批量处理，性能更好

为什么不用递归 CTE 替代？什么时候该换思路

如果你只是想查树形数据（如组织架构、分类目录），优先用递归 CTE，它原生支持 MAXRECURSION，且性能远优于存储过程递归：

WITH Tree AS (
    SELECT ID, Name, ParentID, 0 AS Level
    FROM Categories WHERE ID = @RootID
    UNION ALL
    SELECT c.ID, c.Name, c.ParentID, t.Level + 1
    FROM Categories c
    INNER JOIN Tree t ON c.ParentID = t.ID
)
SELECT * FROM Tree OPTION (MAXRECURSION 10);

但递归 CTE 有硬限制：