如何避免SQL触发器导致递归调用-SQL-PHP中文网

直接在触发器内修改监听表必然出错：mysql报error 1442，sql server静默卡死，postgresql默认放行需手动拦截；唯一可靠解法是运行时标记（如context_info）或深度控制（如pg_trigger_depth()），且必须确保会话上下文一致性。

如何避免sql触发器导致递归调用

直接在触发器里修改它监听的那张表，一定会出问题——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、MySQL 的会话变量、PostgreSQL 的 pg_trigger_depth()，全都要求你在触发器外发起的语句与触发器内逻辑共享同一连接/会话。连接池场景下最容易漏掉重置，比如 pymysql 复用连接后，max_sp_recursion_depth 还是上次设的值，就可能让防护失效。