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。
