MySQL触发器禁止递归修改自身表，报错ERROR 1442；用@in_trigger变量拦截不可靠，推荐UUID+临时表记录执行路径，或由存储过程显式传参控制跳过逻辑。
触发器里改同一张表，为什么突然卡死或报错
很多开发者都踩过这个坑：在MySQL的触发器里，试图去修改触发器所在的同一张表。比如，在一个AFTER UPDATE触发器里，又执行了一条UPDATE语句来更新同一张表。结果呢？MySQL会直接抛出一个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.。这其实是MySQL的一种保护机制，默认就禁止了这种直接的递归操作。
但问题往往更隐蔽。不少人以为，只要不直接UPDATE同一张表就万事大吉了。于是，他们设计了嵌套触发器，或者通过A表触发B表，B表再触发回A表的联动逻辑。表面上看，没有违反那条“禁令”，但一不小心就形成了一个逻辑闭环。最终导致的结果，不是报错，而是更棘手的状况：数据库CPU使用率飙升，事务被卡住无法提交，甚至出现难以追踪的数据错乱。这种“静默”的无限循环，排查起来反而更费劲。
用 @in_trigger 全局会话变量做递归拦截是否可靠
面对递归问题，一个流传甚广的“土办法”是使用会话变量@in_trigger来拦截。典型的写法是：在触发器开头设置SET @in_trigger := 1，在业务逻辑结束后清空它，中间则通过判断IF @in_trigger THEN LEA VE proc_label; END IF;来跳过递归调用。
这个方法听起来挺巧妙，但实际上并不可靠，存在几个硬伤：
- 状态覆盖问题：
@in_trigger是会话级变量。想象一下，如果一条批量更新语句影响了多行数据，触发器会被多次触发。这个变量就会被反复设置和清空，状态完全混乱，根本无法准确区分“当前调用是来自外部还是来自自身的递归”。 - 控制流失控：如果触发器内部又调用了存储过程，而这个过程里也操作了这个变量，那么整个状态管理就彻底失控了，预测它的行为变得几乎不可能。
- 主从一致性问题：在MySQL 8.0及以上版本，如果开启了
binlog_format = ROW模式进行主从复制，这个会话变量的状态是不会被同步到从库的。这会导致主库和从库上触发器的执行逻辑不一致，埋下数据不一致的隐患。
说到底，最理想的判断依据其实是“触发器执行的栈深度”，但遗憾的是，MySQL并未向开发者暴露这个信息。因此，我们需要退而求其次，寻找一种在MySQL上下文中唯一且可追踪的标识来解决问题。
推荐方案：用 UUID() + 临时表记录触发路径
这里推荐一个更稳健的思路：将“本次SQL语句执行的唯一性”作为判断递归的锚点，而不是依赖一个容易变化的变量状态。具体操作可以分为三步走：
- 生成唯一标识：在触发器的最开始，生成一个全局唯一的
UUID()。 - 记录与检查：将这个UUID尝试插入到一张专门用于追踪的临时表（例如
temp_trigger_trace）中，并为trace_id字段设置UNIQUE KEY约束。插入前，先检查这个ID是否已经存在。如果插入失败（因为唯一键冲突），就说明当前调用是递归触发的，直接退出触发器逻辑。 - 清理痕迹：在触发器正常结束前，删除这条追踪记录。也可以利用
ON COMMIT DROP选项创建事务级临时表，让数据库在事务提交后自动清理。
下面是一个BEFORE INSERT触发器的示例片段：
CREATE TRIGGER tr_user_insert_pre
BEFORE INSERT ON user FOR EACH ROW
BEGIN
DECLARE v_trace CHAR(36);
SET v_trace = UUID();
-- 尝试插入 trace_id，失败即说明已存在（递归）
INSERT IGNORE INTO temp_trigger_trace (trace_id) VALUES (v_trace);
IF ROW_COUNT() = 0 THEN
LEA VE proc_exit;
END IF;
-- 正常业务逻辑...
IF NEW.status = 'active' THEN
INSERT INTO user_log (user_id, action) VALUES (NEW.id, 'activated');
END IF;
DELETE FROM temp_trigger_trace WHERE trace_id = v_trace;
END;
需要特别注意几个细节：temp_trigger_trace这张表最好使用ENGINE=MEMORY引擎，或者创建为TEMPORARY临时表，以避免在事务中产生不必要的表锁。另外，这张表必须在会话初始化时就创建好，因为MySQL不允许在触发器内部执行CREATE TEMPORARY TABLE语句。
比变量更稳的替代：用触发器参数传状态位
如果触发器的使用场景比较特定，比如它只被某个特定的存储过程所调用，那么还有一个更干净利落的解决方案：根本不去“拦截”递归，而是让调用方来显式控制触发器的行为。
- 设计传参接口：在调用触发器的存储过程中，增加一个参数，例如
IN p_skip_trigger BOOLEAN DEFAULT FALSE。 - 触发器内读取参数：触发器通过读取这个参数的值（可以通过用户变量传递，或者在表中设计一个临时状态字段），来决定是否执行核心逻辑。
- 规范调用入口：关键在于，所有非人工直接执行的DML操作，都必须通过这个存储过程入口。只有在人工调试时，才将
p_skip_trigger参数设为FALSE，允许触发器完整执行。
这种方法比在触发器内部费心猜测“我是不是被递归调用了”要可控得多。它揭示了一个更深层的道理：递归问题往往不是一个纯粹的技术难题，而是一个设计问题。当你发现需要靠状态位来兜底时，就应该停下来回头审视一下：这张表的数据变更，是否真的必须由触发器来驱动？有没有可能将其改为应用层的事件监听，或者通过定时任务来补偿处理？
真正考验人的，从来不是“如何防止递归”的技巧，而是“如何避免让递归发生”的设计。触发器递归，很多时候暴露的是表结构之间耦合过紧、业务状态流转缺乏一个中心协调机制的问题。解决它，可能需要跳出数据库的层面去思考。
