为什么在触发器里改本表数据会引出无限循环，如何避免自触发死循环问题？

本文共计1043个文字，预计阅读时间需要5分钟。

这不是循环执行了一堆子句才崩溃的问题，而是MySQL在语法解析阶段就截断了——只要触发器体内出现对当前表的+UPDATE+、+INSERT+或+DELETE+，不管是否有条件、改没改动到同一行，一例拒绝执行，并抛出+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 —— 明知是同一张表，还硬上
• BEFORE 触发器里用 SET NEW.col = ... 很安全，但紧接着又在同一个触发器里调用一个存储过程，而该过程内部偷偷 UPDATE users
• 跨库操作：在 db1.t1 的触发器里 UPDATE db2.t2，结果 db2.t2 上也有个触发器，反向更新回 db1.t1

BEFORE 和 AFTER 类型对循环风险的影响完全不同

BEFORE INSERT/UPDATE 中只操作 NEW（比如 SET NEW.updated_at = NOW()）完全不会触发新事件，是唯一允许“修改本表语义”的安全位置；而 AFTER 类型一旦执行任何 DML 操作，就立刻进入递归链起点。

常见误判：

• 以为 “只改一行 + 加了 WHERE” 就没事 —— 错。MySQL 不看逻辑，只看表名是否命中
• 以为 “我用的是 INSERT … ON DUPLICATE KEY UPDATE” 就能绕开 —— 错。它只触发 BEFORE INSERT 和 AFTER INSERT，根本不会进 UPDATE 类触发器，但如果你在 AFTER INSERT 里又去 UPDATE 本表，照样报 1442
• 在 BEFORE UPDATE 里设了 NEW.status = 'done'，然后在 AFTER UPDATE 里再根据 status 做同步 —— 这没问题；但如果 AFTER 里又去 UPDATE 同一张表，就又踩坑

max_sp_recursion_depth = 1 是调试开关，不是修复手段

设成 1 的真实作用是让递归刚冒头就被掐断，强制暴露问题链路。但它不能代替逻辑修正，反而可能掩盖更深层的设计缺陷。

必须注意：

• 这个变量只能在会话级设置：SET SESSION max_sp_recursion_depth = 1，不能在触发器里写 SET，MySQL 语法不允许
• 用连接池（如 pymysql）时，每次从池里取连接后都得重置，否则可能复用到之前设过 2 或 0 的连接
• 设成 0 表示不限制，等于放弃防护；设成 2 可能让你误以为“两层够用了”，但第三层一来还是崩
• 线上紧急排查时，优先跑 SHOW PROCESSLIST，找状态卡在 Updating 或 Waiting for table metadata lock 的线程，而不是盯着日志等报错

真正能落地的三种绕过方式

没有银弹，只有按场景选最稳的那条路：

• 用中间表解耦：在触发器里只写 INSERT INTO trigger_queue (table_name, pk_id, action) VALUES ('users', NEW.id, 'sync_to_log')，再由事件调度器或外部脚本消费，彻底隔离 DML 调用链
• 加跳过标记字段：在目标表（如 t2）加 skip_trigger TINYINT DEFAULT 0，主触发器中 UPDATE t2 SET x = NEW.x, skip_trigger = 1 WHERE id = NEW.t2_id，然后在 t2 的触发器开头加 IF OLD.skip_trigger = 1 THEN LEAVE proc_label; END IF;
• 用会话变量临时跳过：外部先 SET @skip_my_trigger = 1，触发器开头判断 IF @skip_my_trigger IS NOT NULL THEN LEAVE proc_label; END IF;，执行完立刻 SET @skip_my_trigger = NULL；注意变量不跨连接，但同连接内必须清理干净

字段名别叫 flag 或 tmp，下次别人维护时真看不懂你在跳什么。