SQL Server中触发器递归导致死锁的典型表现
在数据库运维中，触发器递归引发的死锁是个典型的“自己挖坑自己跳”的问题。想象一下这个场景：你在一个表的 AFTER INSERT 触发器里，又去更新了同一张表。这个更新操作，好巧不巧，再次触发了同一个触发器。于是，一个无限循环就此诞生。
它的外在表现通常很直观：执行语句长时间“卡住”，仿佛石沉大海。用 sp_who2 命令查看，往往会发现进程状态显示为 WAITFOR 或 LCK_M_U 这类锁等待。如果SQL Server的“耐心”被耗尽了，它就会直接抛出一个明确的错误：Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)。这行报错，几乎就是递归触发的“身份证”。
如何关闭触发器的递归调用（SERVER 级开关）
要根治这个问题，最直接的办法是从源头切断递归的可能性。SQL Server 默认是允许触发器间接递归的（比如A表触发器更新B表，B表触发器又更新回A表）。但数据库层面提供了一个“总开关”，可以一键禁止这种链式反应。
这个开关不是写在触发器逻辑里的，而是一个数据库级别的配置项：
- 执行命令：
ALTER DATABASE [YourDB] SET RECURSIVE_TRIGGERS OFF。这条命令会禁止数据库中所有AFTER触发器的间接递归（需要注意的是，INSTEAD OF触发器不受此设置影响）。 - 设置对新连接立即生效，已有连接需要重新连接后才能生效。
不过，下这个“猛药”前得想清楚：它影响的是整个数据库的所有表。如果你的业务逻辑里，本就设计有跨表的触发链（例如，插入订单 → 更新库存表 → 再记录日志表），关闭递归后，这条链就会从中间断掉，可能导致数据不一致。所以，全局关闭是一把双刃剑。
触发器内部如何避免自我触发（推荐做法）
相比“一刀切”地关闭全局递归，更精细、更可控的做法是在触发器内部加上防护逻辑。这尤其适用于那些需要保留递归能力，但又必须防止死循环的复杂场景。
业内常用的几种防护策略包括：
- 检查嵌套层级：这是最推荐的方法。在触发器的第一行就加入判断：
IF TRIGGER_NESTLEVEL(OBJECT_ID(N‘dbo.YourTriggerName’)) > 1 RETURN。当检测到当前触发器已经被嵌套调用时，直接退出，避免无限深入。 - 使用状态标志：通过临时表或表变量，缓存一个“正在处理中”的状态。在触发器开头检查：
IF EXISTS(SELECT 1 FROM #InTrigger) RETURN。这种方法给了开发者更大的控制灵活性。 - 重构设计：从根本上避免在
AFTER触发器中更新同一张表。可以考虑改用INSTEAD OF触发器，并在其中显式完成INSERT或UPDATE操作。或者，将可能引发递归的副作用逻辑，剥离到存储过程中进行异步处理。
MySQL / PostgreSQL 用户注意：机制完全不同
如果你同时在使用多种数据库，这里有个重要提醒：不同数据库对触发器递归的处理机制天差地别，千万别把SQL Server的经验直接套用过去。
以MySQL为例，它压根没有内置的触发器递归开关。系统变量 max_sp_recursion_depth 只控制存储过程的递归深度，对触发器无效。在MySQL里，防止递归全靠开发者“手动挡”操作，比如在表里新增一个 is_processing 状态字段，或者使用 GET_LOCK() 函数来实现会话级的互斥锁。
再看PostgreSQL，它的触发器默认是不递归的。但是，如果触发器内的 UPDATE 语句恰好又导致了同一个触发事件，它仍然会再次被触发。因此，在PostgreSQL中，你需要借助 pg_trigger_depth() 函数来判断当前的嵌套深度，或者使用 SET LOCAL 命令设置会话级别的临时变量来标记执行状态。
总而言之，面对触发器递归问题，关键是要先理解你所用的数据库到底是怎么“玩”的。不同数据库的“递归”定义和控制粒度差异很大，对症下药才是解决问题的根本。
