sql server中触发器自我更新引发死循环的典型表现是语句卡住、sp_who2显示waitfor或lck_m_u锁等待，或报错“maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)”。
触发器自我更新引发的死循环怎么识别
SQL Server 中最典型的死循环是 AFTER INSERT/UPDATE 触发器里又 UPDATE 同一张表，导致触发器再次被调用。表现不是报错“死锁”，而是语句卡住、sp_who2 显示 WAITFOR 或 LCK_M_U 等待，甚至直接报错 Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)。
MySQL 和 PostgreSQL 没有内置递归深度限制，但会因重复加锁或条件判断失效进入逻辑死循环——比如触发器里 UPDATE t SET status = 'done' WHERE id = NEW.id，而该更新又满足触发条件，持续触发自身。
SQL Server 中防止触发器递归的两种手段
全局关递归简单粗暴，但影响所有表；局部防护更可控：
-
ALTER DATABASE [YourDB] SET RECURSIVE_TRIGGERS OFF：禁用整个库的 AFTER 触发器间接递归（INSTEAD OF 不受影响），已有连接需重连才生效 - 在触发器开头加防护逻辑：
IF TRIGGER_NESTLEVEL(OBJECT_ID(N'dbo.YourTriggerName')) > 1 RETURN，只拦同一触发器的嵌套调用，不影响跨表链式触发
注意：TRIGGER_NESTLEVEL() 返回的是当前会话中该触发器被调用的层数，不是所有触发器的总层数，所以必须传入具体对象 ID 才准确。
MySQL / PostgreSQL 怎么避免触发器内重复加锁
它们不支持 RECURSIVE_TRIGGERS 开关，得靠开发者手动控制锁边界：
- MySQL：用
GET_LOCK('trigger_lock_order_123', 0)尝试获取会话级互斥锁，失败则直接退出；或新增字段如is_processing TINYINT DEFAULT 0，UPDATE 前先检查并 SET，完成后清零 - PostgreSQL：用
pg_trigger_depth()判断当前是否已在触发器中执行；或配合SET LOCAL myapp.in_trigger = true+CURRENT_SETTING('myapp.in_trigger', true)实现会话标记 - 共性原则：所有 DML 必须走唯一索引，禁止
WHERE status = 'pending'这类范围条件——它会触发 gap lock，让多个并发事务在相同间隙上反复争抢
为什么在触发器里加 SELECT ... FOR UPDATE 很危险
看似能“预锁”，实则扩大锁范围、延长持有时间，反而加剧冲突：
- 若你在触发器开头写
SELECT id FROM log_table WHERE order_id = NEW.order_id FOR UPDATE，这把锁会一直持到主事务提交，哪怕后续根本没用到它 - 如果主事务本身已锁了
orders表某行，而这条SELECT ... FOR UPDATE又要去锁log_table，就等于人为制造「orders → log_table」的固定锁序——但其他业务代码可能按相反顺序操作，反而固化死锁路径 - 真正安全的做法是：把日志写入改为异步（如写入缓冲表 + 定时任务 flush），或改用应用层发 MQ，彻底剥离锁耦合
触发器的锁行为本质不可控，越想用加锁来“驯服”它，越容易陷入更深的等待环。最轻量的解法永远是：让它只做确定性高的单点更新，且目标表索引足够窄、足够唯一。
