MySQL触发器中UPDATE本表直接报ERROR 1442，是语法解析阶段强制拦截，非逻辑错误；正确做法是BEFORE中用SET NEW赋值，AFTER中改用中间表或异步解耦，严禁任何对本表的DML操作。
MySQL 触发器里 UPDATE 本表直接报 ERROR 1442 怎么办
这不是逻辑写错了，是 MySQL 在语法解析阶段就拦截——只要触发器代码里出现 UPDATE orders、INSERT INTO orders 或 DELETE FROM orders，不管 WHERE 条件多精准、改没改到同一行，立刻抛出 ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger。
BEFORE 触发器中用 SET NEW.col = ... 安全，它只修改待插入/更新的行值，不触发新事件；AFTER 触发器里哪怕只写一行 UPDATE orders SET updated_at = NOW() WHERE id = NEW.id 也会被拦。
常见误判：
- 以为
SELECT ... FOR UPDATE不触发限制 → 实际上某些隔离级别下仍可能被拦 - 用
INSERT IGNORE或REPLACE INTO写本表 → 同样算“修改本表”，不豁免 - 试图用
SET SQL_LOG_BIN = 0绕过 → 只影响复制，不解锁触发器执行时的表使用检查
SQL Server 中如何防住 AFTER 触发器自调用死循环
默认允许间接递归（比如 t1 触发器更新 t2，t2 的触发器又更新 t1），但一旦嵌套深度超 32 层，直接报 Msg 217, Level 16: Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)，语句立即中止，不回滚、不重试。
推荐做法分两层：
- 数据库级硬控制：
ALTER DATABASE [YourDB] SET RECURSIVE_TRIGGERS OFF—— 立即禁用所有 AFTER/INSTEAD OF 触发器的间接递归，但需sysadmin权限 +RECONFIGURE生效；注意：影响整个库，且已有连接要重连才生效 - 触发器内软防护：
IF TRIGGER_NESTLEVEL(OBJECT_ID(N'dbo.YourTriggerName')) > 1 RETURN—— 比@@NESTLEVEL更准，能区分“合法嵌套”和“自调用死循环”
别用临时表或全局变量存标记——临时表跨会话不可见，@@SPID 在并行执行下可能重复。
跨表触发链中怎么精准判断哪几列真被改了
UPDATE(col) 函数只检测 SET 子句是否显式写了该列名，不关心值是否真变；它防不住跨表循环（比如 t1 触发器更新 t2，t2 触发器又更新 t1）。
必须用 COLUMNS_UPDATED() 配合位运算：
- 判断第 1 列（索引从 0 开始）被改：
IF (COLUMNS_UPDATED() & POWER(2, 1)) = POWER(2, 1) - 字段顺序影响位图位置，改表结构（如增删列）后必须同步调整位运算逻辑
- 避免在触发器里调用含 DML 的存储过程——即使过程本身不操作当前表，只要路径中可能间接触发，仍会被拦截
PostgreSQL 和 MySQL 的递归控制思路完全不同
PostgreSQL 默认不递归，但若触发器内执行 UPDATE 引起相同事件，仍会再次触发。必须用 pg_trigger_depth() 判断嵌套深度，或用 tg_op + 会话级变量（SET LOCAL）标记。
MySQL 的 innodb_recursive_triggers 默认关闭，本质是防自循环：对同一张表的二次修改（如 users 触发器里又 UPDATE users）会被直接拒绝，报错 ERROR 1442。开启它后，还需同步检查 max_sp_recursion_depth（默认 6），否则会在第 7 层报 ERROR 1456。
跨表链式触发（t1 → t2 → t3）不受此变量控制，但主从复制时从库会跳过 t2/t3 上的触发器——这本身就是一种隐式“禁用”。
不同数据库的“递归”定义和控制粒度差异很大，别直接套用 SQL Server 的 RECURSIVE_TRIGGERS 思路。
