MySQL触发器中禁止UPDATE本表，会直接报ERROR 1442，这是InnoDB引擎级硬限制，旨在防止递归和死锁，不可通过配置绕过。
MySQL触发器里UPDATE本表直接报ERROR 1442，不是bug是硬限制
只要触发器代码中出现UPDATE orders、INSERT INTO orders或DELETE FROM orders，哪怕加了WHERE id = NEW.id，MySQL解析阶段就拦截并抛出ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger。这不是配置能绕过的，是InnoDB为防递归和死锁做的引擎级保护。
SQL Server用CONTEXT_INFO标记会话，比@@NESTLEVEL更稳
SQL Server允许自更新，但默认开启递归（RECURSIVE_TRIGGERS = ON），仅靠@@NESTLEVEL > 1判断容易误判合法嵌套。真正可靠的是会话级上下文标记：
- 应用层执行业务SQL前先设标记：
SET CONTEXT_INFO 0x54524947474552（ASCII编码的"TRIGGER"） - 触发器开头立即检查：
IF CONTEXT_INFO() = 0x54524947474552 RETURN - 禁用
DISABLE TRIGGER方案——并发下可能一个请求禁用后还没启用，另一个已进入
PostgreSQL只能在BEFORE中改NEW行，AFTER里写DML必报错
PostgreSQL对触发器修改本表有明确分水岭：
-
BEFORE INSERT OR UPDATE中可安全赋值：NEW.updated_at := NOW()，不触发新事件 -
AFTER触发器里任何INSERT/UPDATE/DELETE当前表操作都会被拒绝 - 若需根据新数据生成关联记录（如订单→库存流水），必须用
PERFORM pg_notify()发通知，由外部消费者处理
所有数据库都该避开的“伪解法”
这些做法看似绕过限制，实则埋雷：
- 在触发器里调用含DML的存储过程——路径中只要可能间接触发本表，仍会被拦
- 用
SELECT ... FOR UPDATE查本表再UPDATE——高并发下极易死锁，且MySQL会升级为间隙锁 - 依赖
UPDATE(column)函数判断字段是否真变化——它只看SET子句是否写了该列名，值没变也返回TRUE - 临时表必须显式在触发器外创建（
CREATE TEMPORARY TABLE），且不能放在触发器内部执行（语法报错）
UPDATE ... WHERE status = 'pending' + @@ROWCOUNT校验来闭环。 
