直接在触发器内修改监听表必然出错：MySQL报ERROR 1442，SQL Server静默卡死，PostgreSQL默认放行需手动拦截；唯一可靠解法是运行时标记（如CONTEXT_INFO）或深度控制（如pg_trigger_depth()），且必须确保会话上下文一致性。
直接在触发器里修改它监听的那张表，一定会出问题——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 还是上次设的值，就可能让防护失效。
