很多循环更新问题，不是“触发器写得不够严谨”，而是数据库本身对自引用触发就有完全不同的处理方式：有的直接拒绝，有的默认递归，有的只给你深度判断工具。下面按 MySQL、SQL Server、PostgreSQL 分别说明哪些写法一定出错、哪些方案能落地，以及最后最容易被忽略的会话上下文风险。
为什么触发器回写自身表容易出问题
直接在触发器中对自身监听的表再次执行 UPDATE、INSERT 或 DELETE，本质上就是把一次数据变更重新送回同一条触发链。问题在于，不同数据库对这条链的处理方式完全不同：
- MySQL：语法级直接拒绝，报
ERROR 1442 - SQL Server：可能静默递归，直到性能异常甚至卡死
- PostgreSQL：默认允许递归，但需要手动用深度判断拦截
因此，像 RECURSIVE_TRIGGERS 这类数据库开关，通常并不能真正解决“监听自己又修改自己”的问题。实际可用的办法，通常只有两类：运行时标记，或者显式深度控制。
MySQL：修改自身监听表会直接触发 ERROR 1442
在 MySQL 里，这不是“可能死循环”，而是会被数据库直接拦下。只要触发器体中出现针对本表的 UPDATE、INSERT 或 DELETE，就会立刻报出 ERROR 1442。
这里要注意，额外加判断条件也没有用。例如即便写了 IF OLD.status != NEW.status，只要触发器中仍然对当前监听表执行修改，MySQL 依旧会拒绝执行。
BEFORE 触发器的安全写法
如果你的目标只是修正即将写入的字段值，应该在 BEFORE 触发器里直接修改 NEW 记录，而不是再去更新原表：
SET NEW.col = ...这类写法的关键点是：只改“即将落库的数据”，不重新发起一次对原表的写操作。
AFTER 触发器需要落库时，改走中间表
如果 AFTER 触发器确实需要把事件持久化下来，比如记日志、同步状态，稳妥做法是拆到中间表，而不是继续回写当前表：
INSERT INTO trigger_queue (table_name, pk, action) VALUES ('users', NEW.id, 'update')这种做法把“触发事件”和“后续处理”拆开，避免在同一触发链里形成自引用。
跨库更新和调试也有误区
- 跨库操作不等于安全：
UPDATE other_db.users如果目标库的对应表也挂了触发器，依然可能递归 - 调试时不要先看日志表有没有写进去，而要先确认
log_warnings = 2，以及log_error指向的路径是否可写
SQL Server：用 CONTEXT_INFO 比 @@NESTLEVEL 更可靠
SQL Server 的难点不在于它会不会报错，而在于它可能安静地递归下去。很多人会先想到 @@NESTLEVEL，但它并不能区分“正常嵌套调用”和“触发器自调用”，在视图触发、存储过程间接调用等路径下，判断并不稳定。
相比之下，CONTEXT_INFO 更适合做运行时标记。它是一个 128 字节的二进制会话变量，每个连接独享，也不会因为嵌套调用被自动覆盖。
推荐的标记与检查方式
常见做法是在业务 SQL 执行前先写入标记：
SET CONTEXT_INFO 0x54524947474552这里的 0x54524947474552 是 "TRIGGER" 的 ASCII 十六进制表示。
然后在触发器开头立即检查：
IF CONTEXT_INFO() = 0x54524947474552 RETURN这样可以在触发器再次被同一连接链路唤起时，直接退出，避免递归继续扩散。
两个容易被忽略的细节
- 不要用
CONVERT(VARCHAR, CONTEXT_INFO())做比较，编码差异或截断都可能导致判断失效 - 如果触发器是由存储过程间接调用，应该在过程开头设标记、结尾清空：
SET CONTEXT_INFO 0x0
这类方案能否稳定工作，取决于你是否把“设置、检查、清理”做成完整闭环。
PostgreSQL：pg_trigger_depth() 能挡一层，挡不住所有间接路径
PostgreSQL 默认允许触发器递归，所以如果不主动拦截，自引用更新很容易一路嵌套下去。最常见的工具是 pg_trigger_depth()，它返回当前触发器的嵌套层数，首次进入时为 1。
但这个函数只能反映“层数”，不能判断这次触发到底是什么事件、是不是你真正想拦的那条链路。所以只看数值，经常还不够。
基础防护：按深度拦截
IF pg_trigger_depth() > 1 THEN RETURN; END IF;这适合先挡掉最直接的再次触发场景。
更细的控制：结合 TG_OP 判断
IF pg_trigger_depth() > 1 AND TG_OP = 'UPDATE' THEN RETURN;把 TG_OP 一起纳入条件后，可以更精确地区分当前是 UPDATE、INSERT 还是其他事件，减少误拦截。
它的边界也要看清
pg_trigger_depth() 只对当前触发器上下文生效。如果触发器调用了函数，而函数内部又间接更新了本表，这种再触发路径仍然可能绕过你的判断。也就是说，它更像是“当前层的保险丝”，不是全链路递归治理工具。
最后一个高频漏点：运行时标记依赖上下文一致性
无论是 SQL Server 的 CONTEXT_INFO、PostgreSQL 的会话级函数，还是 MySQL 的会话变量思路，这类方案都建立在同一个前提上：执行上下文必须稳定且可控。
一旦出现以下情况，标记就可能失效或污染：
- 连接被复用，但旧标记没有清理干净
- 事务中断后状态残留
- 并发请求共享了你原本以为独立的执行链路
所以不要假设“标记设一次就一直有效”。真正可落地的做法，是把标记设置、触发器检查、事务范围和清理动作一起设计，确保整个执行路径前后一致。
