MySQL触发器中UPDATE本表直接报ERROR 1442，是语法解析阶段的硬性拦截，非死锁或配置问题；唯一安全写法是在BEFORE触发器中用SET NEW.field = value赋值，AFTER中任何DML均被拒。
MySQL里UPDATE本表直接报ERROR 1442，不是死循环而是语法拦截
你在AFTER UPDATE触发器里写UPDATE orders SET status = 'done' WHERE id = NEW.id，MySQL根本不会让它执行到锁或事务阶段——解析时就抛出ERROR 1442 (HY000)。这不是配置没开、隔离级别不对，也不是WHERE条件不够精确，只要目标表名和触发器所属表完全一致，立刻拦截。
常见误判包括：以为加了IF OLD.status != NEW.status就能绕过；以为用INSERT ... ON DUPLICATE KEY UPDATE能躲开；甚至以为跨库UPDATE（如UPDATE db2.t2）就安全——但如果db2.t2上也有反向写回当前库的触发器，照样触发ERROR 1442。
- BEFORE触发器中只允许
SET NEW.field = value，它不产生新SQL，不申请锁，不触发新事件 - AFTER触发器里哪怕只改一行、只更新一个字段，任何DML操作都禁止
-
max_sp_recursion_depth只是调试开关，设成1只能让错误提前暴露，不能绕过限制
SQL Server必须用CONTEXT_INFO做会话级标记，别信@@NESTLEVEL
SQL Server允许在AFTER UPDATE里直接UPDATE users SET updated_at = GETDATE() WHERE id = inserted.id，但它会再次触发自身，形成静默递归。表现是连接卡住、sp_who2显示LCK_M_U等待，或最终爆Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)。
RECURSIVE_TRIGGERS = OFF对A→A自引用完全无效；@@NESTLEVEL在并行执行下不准，且无法区分合法嵌套和非法自调用。
- 业务SQL开头设
SET CONTEXT_INFO 0x54524947474552（"TRIGGER"的ASCII十六进制） - 触发器第一行必须检查
IF CONTEXT_INFO() = 0x54524947474552 RETURN - 禁用
DISABLE TRIGGER+ENABLE TRIGGER方案——并发下极易漏掉请求
PostgreSQL需手动用pg_trigger_depth()拦截，且仅靠它还不够
PostgreSQL默认允许触发器内UPDATE本表，但每次都会再触发——所以你得自己拦。关键函数是pg_trigger_depth()，首次触发返回1，第二次返回2。开头加IF pg_trigger_depth() > 1 THEN RETURN; END IF;是最小必要条件。
但仅靠这个不够：如果触发器逻辑依赖TG_OP或TG_TABLE_NAME，比如只想在AFTER INSERT时跳过，而在BEFORE UPDATE时仍执行，则需组合判断：
IF TG_OP = 'INSERT' AND pg_trigger_depth() > 1 THEN RETURN;- 字段顺序变更会影响
COLUMNS_UPDATED()位图位置，改表结构后必须同步调整位运算逻辑 - 避免在触发器里调用含DML的存储过程，即使过程不直接操作当前表，路径中可能间接触发
真正难的不是写RETURN，而是确保所有写入口都走同一套防护
触发器防不住直连数据库的运维脚本、旧服务、ETL工具——只要有一个账号有UPDATE权限且绕过触发器，防护就形同虚设。应用层补偿（如发Kafka消息）最干净，但引入外部依赖；事件调度器（EVENT）延迟毫秒到秒级，适合非实时场景；中间表+轮询方式简单，但需额外维护调度逻辑。
最容易被忽略的一点：BEFORE触发器里用SET NEW.field = ...看似安全，但如果紧接着调用一个存储过程，而该过程内部偷偷UPDATE了同一张表，照样崩——MySQL的拦截是全路径扫描，不是单条语句检查。
