MySQL触发器中直接操作监听表会立即报ERROR 1442，属语法级硬拦截；安全做法仅限BEFORE中SET NEW字段、中间表解耦或运行时标记跳过。
MySQL触发器里直接UPDATE、INSERT或DELETE自己监听的表，不是“可能死循环”，而是立刻报ERROR 1442——这是语法级硬拦截，连执行机会都不给。所谓“递归”在MySQL里根本走不到第二层，但很多人误以为加了IF OLD.status != NEW.status就能绕开，结果在AFTER触发器里偷偷改本表，反而让问题更隐蔽。
为什么ERROR 1442不是死循环而是语法拒绝
MySQL在解析触发器体时就检查所有DML语句的目标表名。只要出现和触发源表同名的UPDATE、INSERT或DELETE，不管有没有WHERE、是否命中同一行、是否嵌套在IF里，一律拒绝并抛出ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。
常见误判点：
- 在
AFTER UPDATE users里写UPDATE users SET updated_at = NOW() WHERE id = NEW.id→ 必报1442 - BEFORE触发器中
SET NEW.col = ...是安全的；但紧接着调用一个含UPDATE users的存储过程 → 同样触发1442 -
INSERT INTO other_db.users也不安全：如果other_db.users上也有触发器，且它反过来操作当前库的表，链路闭环即递归
max_sp_recursion_depth = 1不是修复手段而是调试开关
这个会话变量只能暴露问题，不能替代逻辑修正。设为1后，MySQL会在第二次触发尝试时立即中断，并报错（如ERROR 1422或锁等待超时），但它不解决“为什么会有第二次触发”这个根本问题。
实操要点：
- 必须用
SET SESSION max_sp_recursion_depth = 1，不能在触发器里写SET（语法不允许） - 连接池场景（如pymysql、Druid）每次获取连接后都得重置，否则可能复用到之前设为0或2的连接
- 设为0等于放弃防护；设为2仍可能在第三层崩，且无法预判哪一层是业务安全边界
- 该设置对存储过程也生效——若触发器调用了含UPDATE的SP，同样会被拦
真正能落地的解法只有三种：移出写操作、运行时标记、中间表解耦
所有“在触发器里加个IF跳过”的方案，本质都是把写操作从触发上下文中剥离出去。没有银弹，只有取舍。
可选路径：
-
BEFORE中只做字段修正：如
SET NEW.updated_at = NOW()、SET NEW.email = LOWER(NEW.email)——不发DML，零风险 -
用中间表解耦：AFTER触发器里只
INSERT INTO trigger_queue (table_name, pk, action, payload) VALUES ('users', NEW.id, 'sync_status', ...)，再由外部脚本或EVENT定时消费 -
运行时标记跳过：应用层先
SET @skip_my_trigger = 1，触发器开头加IF @skip_my_trigger IS NOT NULL THEN LEAVE proc_label; END IF;，执行完再SET @skip_my_trigger = NULL；注意用户变量是会话级，不同连接互不影响，但同连接必须清理
最容易被忽略的一点是：所有标记方案（CONTEXT_INFO、用户变量、中间表）都依赖执行上下文的一致性。一旦连接复用、事务未提交、或跨库调用链路不清，标记就可能失效。线上出问题时，别急着改触发器，先跑SHOW PROCESSLIST看有没有线程卡在Updating或Waiting for table metadata lock——那才是真实现场。
