直接在触发器里修改自身监听表肯定会出问题——MySQL语法级会报ERROR 1442，SQL Server会静默递归致卡死，PostgreSQL默认递归得用pg_trigger_depth()>1手动拦截。数据库开关（如RECURSIVE_TRIGGERS）对自引用基本无效，唯一靠谱的解法是运行时标记（如SQL Server的CONTEXT_INFO）或深度控制。

直接在触发器中对自身监听的表进行修改，必然会引发问题——MySQL会报出ERROR 1442错误，SQL Server则会静默递归直至卡死，PostgreSQL默认允许但需手动拦截。依靠数据库开关（如RECURSIVE_TRIGGERS）基本无法解决问题，真正可行的解决方案是运行时标记或深度控制。

MySQL 触发器里 UPDATE 自己表会怎样

不是“可能死循环”，而是语法级拒绝：只要触发器体里出现对本表的 UPDATE/INSERT/DELETE，立刻报错 ERROR 1442。哪怕加了 IF OLD.status != NEW.status 判断也没用。

• BEFORE 触发器安全做法：用 SET NEW.col = ... 修改即将写入的值，不碰原表
• 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 更可靠

@@NESTLEVEL 不区分“合法嵌套”和“自调用”，在视图触发、存储过程调用等路径下行为不稳定；CONTEXT_INFO 是 128 字节二进制会话变量，每个连接独享，且不会被嵌套覆盖。

• 业务 SQL 执行前设标记：SET CONTEXT_INFO 0x54524947474552（即 "TRIGGER" 的 ASCII 十六进制）
• 触发器开头立即检查：IF CONTEXT_INFO() = 0x54524947474552 RETURN
• 避免用 CONVERT(VARCHAR, CONTEXT_INFO()) 比较——编码或截断会导致失效
• 若触发器被存储过程调用，过程开头设标记、结尾清空：SET CONTEXT_INFO 0x0

PostgreSQL pg_trigger_depth() 为什么不能只看数值

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;
• 注意：该函数只对当前触发器生效，无法拦截由函数间接引发的再触发

最易被忽略的点是：所有运行时标记方案都依赖执行上下文的一致性——SQL Server 的 CONTEXT_INFO、PostgreSQL 的会话级函数、MySQL 的会话变量设置，一旦连接复用、事务未清理或并发干扰，标记就可能失效或污染。别假设“设一次就永远有效”。

《夸克》非常好用的免费AI浏览器

下载APP查看