trigger_nestlevel() 返回当前触发器在嵌套链中的层级数，仅在触发器内有效，不传参查自身层级，传参可查指定触发器；它不统计 ddl 触发器，且超 32 层前即报错。

如何用 TRIGGER_NESTLEVEL() 查当前嵌套深度

TRIGGER_NESTLEVEL() 是 SQL Server 提供的系统函数，直接返回当前触发器在嵌套链中的层级数。它不依赖外部工具或视图，只在触发器执行上下文中有效——也就是说，你不能在普通查询窗口里直接执行它来“测深度”，必须把它写进触发器体内部，再通过 PRINT 或日志表记录。

常见错误是把它当全局状态函数用，比如在 SSMS 新建查询里执行 SELECT TRIGGER_NESTLEVEL()，结果永远返回 0（因为没在触发器中运行）。

• 调用时可传参：TRIGGER_NESTLEVEL(@trigger_id) 能查指定触发器的嵌套次数；不传参则查当前正在执行的触发器层级
• 对同一触发器多次嵌套（如递归更新自己），TRIGGER_NESTLEVEL() 返回的是该触发器自身的嵌套计数，不是整个链总深度
• 若触发器类型是 INSTEAD OF，它也参与计数；但 DDL 触发器 不计入该函数统计范围

为什么 TRIGGER_NESTLEVEL() 返回值突然跳变

嵌套深度不是线性累加的，它受触发器类型和执行路径影响。例如：

• AFTER INSERT 触发器更新了表 B → 表 B 的 AFTER UPDATE 触发器被激活 → 此时 TRIGGER_NESTLEVEL() 在 B 的触发器里返回 2
• 但如果 B 的触发器是 INSTEAD OF UPDATE，且它内部又显式执行了 UPDATE 同一张表，SQL Server 可能不会递增嵌套计数（取决于是否真正引发新触发）
• 启用 RECURSIVE_TRIGGERS 时，直接递归会严格递增；禁用后，哪怕逻辑上像递归，TRIGGER_NESTLEVEL() 也可能卡在 1

所以不能单靠这个函数判断“有没有循环”，它只反映 SQL Server 实际走过的触发路径层级。

结合 @@NESTLEVEL 区分触发器与存储过程嵌套

@@NESTLEVEL 返回的是当前会话中所有 T-SQL 执行块（含存储过程、触发器、函数）的总嵌套深度，而 TRIGGER_NESTLEVEL() 专指触发器部分。两者差值能帮你定位问题来源：

• 在触发器里执行 SELECT @@NESTLEVEL, TRIGGER_NESTLEVEL()，若前者比后者大 2，说明触发器内调用了 1 层存储过程
• 如果 TRIGGER_NESTLEVEL() = 0 但 @@NESTLEVEL > 1，基本可以断定当前不在任何触发器中（比如误写在普通 SP 里）
• 二者同时达到 32 就触发错误：“超出了存储过程、函数、触发器或视图的最大嵌套层数(最大层数为 32)”

嵌套过深时，TRIGGER_NESTLEVEL() 还能取到值吗

不能。一旦嵌套超过 32 层，SQL Server 会在第 33 次尝试进入触发器前就抛出错误，事务回滚，后续代码（包括 TRIGGER_NESTLEVEL() 调用）根本不会执行。你看到的错误信息是：

Msg 217, Level 16, State 1, Procedure xxx, Line y<br>Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32).

这意味着：别指望靠它来“预警”，它本身是结果，不是探针。真要防爆，得在关键触发器开头加判断：

IF TRIGGER_NESTLEVEL() > 30<br>BEGIN<br>    RAISERROR('Trigger nest too deep', 16, 1);<br>    RETURN;<br>END

注意，这个守卫只对当前触发器生效，无法阻止其他触发器继续嵌套——真正的控制点在服务器配置 nested triggers 和数据库选项 RECURSIVE_TRIGGERS。