SQL Server 递归存储过程最大嵌套层数默认为32且只读不可配置，唯一变通方式是启动时加-T2510跟踪标志（不推荐）；实际应通过输入参数@level主动计数并在入口校验，避免依赖@@NESTLEVEL或引擎报错。
SQL Server 中如何设置递归存储过程的最大嵌套层数
SQL Server 默认允许最多 32 层嵌套调用（含存储过程、触发器、函数等），超出会报错 Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)。这个限制是全局的、不可为单个过程单独配置的，只能通过服务器级配置或代码规避。
-
sp_configure 'nested triggers'控制的是触发器是否可嵌套，和递归深度无关，别混淆 - 真正影响递归深度的是
max nested level配置项，但它**只读**，不能用sp_configure修改 - 唯一能调整它的办法是启动 SQL Server 时加 trace flag
-T2510（仅限企业版且不推荐生产使用） - 更实际的做法：在过程里自己计数 + 提前退出，而不是依赖引擎报错才中断
递归存储过程中怎么安全计数并防止爆栈
靠 SQL Server 自动检测太被动，容易在第 32 层才失败，还可能卡住事务或锁表。应该主动控制递归层级，在进入前检查当前深度。
- 用输入参数传入当前层级，比如
@level INT = 1，每次递归调用时传@level + 1 - 开头立刻判断：
IF @level > 20 BEGIN RAISERROR('Recursion too deep', 16, 1); RETURN; END - 避免用
@@NESTLEVEL判断——它返回的是「当前会话中所有嵌套对象总层数」，包括调用链里的触发器、UDF 等，数值不稳定、不可控 - 如果过程可能被多种方式调用（SSIS、应用直连、其他 SP），统一入口必须校验
@level，不能假设调用方会传
为什么不用 CTE 递归替代存储过程递归
对树形结构遍历（如组织架构、分类路径），WITH RECURSIVE（SQL Server 叫 CTE）通常比递归 SP 更可靠、更快，且深度限制可显式控制。
- CTE 的递归部分受
OPTION (MAXRECURSION n)控制，比如OPTION (MAXRECURSION 100)，设 0 表示无限制（慎用） - CTE 是声明式逻辑，SQL Server 查询优化器能更好估算和剪枝；而递归 SP 是命令式，每层都走一次执行计划编译+上下文切换，开销大
- CTE 无法做 DML（如边查边更新父节点状态），这时才被迫用递归 SP —— 但务必补上
@level校验和事务边界保护
MySQL / PostgreSQL 用户注意：这问题根本不存在
MySQL 没有存储过程递归深度限制（只受 stack size 和 max_sp_recursion_depth 影响，后者默认 0 即不限）；PostgreSQL 的 max_stack_depth 是整个 backend 进程栈限制，不是针对函数嵌套层数。
- MySQL 中要改限制，设
max_sp_recursion_depth系统变量（动态可调），但值为 0 才表示“不限”，不是“不限制”而是“由系统栈决定” - PostgreSQL 中递归函数不会因“层数”报错，但真跑太深会触发
ERROR: stack depth limit exceeded，此时得调大max_stack_depth并重启服务 - 跨数据库写迁移脚本时，别把 SQL Server 的
@level防御逻辑直接删掉——虽然目标库没 32 层限制，但业务逻辑本身可能仍需要防无限循环
递归深度从来不是纯配置问题，而是控制流设计问题。最易被忽略的是：把 @@NESTLEVEL 当成安全计数器，它在复杂调用链里会漏算或误算，导致防御失效。
