MySQL触发器禁止递归修改自身表，报错ERROR 1442；用@in_trigger变量拦截不可靠，推荐UUID+临时表记录执行路径，或由存储过程显式传参控制跳过逻辑。
触发器里改同一张表，为什么突然卡死或报错
MySQL 默认禁止触发器递归修改自身表（比如 AFTER UPDATE 里再 UPDATE 同一张表），会直接报错 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.。但很多人误以为“只要不用 UPDATE 就安全”，结果在嵌套触发器或跨表联动时，因逻辑闭环导致无限循环——表面不报错，却 CPU 暴涨、事务卡住、数据错乱。
用 @in_trigger 全局会话变量做递归拦截是否可靠
不可靠。虽然常见写法是开头设 SET @in_trigger := 1，结尾清空，中间加 IF @in_trigger THEN LEAVE proc_label; END IF;，但它有硬伤：
-
@in_trigger是会话级变量，同一连接内多次触发（如批量更新多行）会被反复覆盖，无法区分“是自己调的还是别人调的” - 如果触发器里调用了存储过程，而过程里又改了该变量，状态就彻底失控
- MySQL 8.0+ 开启
binlog_format = ROW时，从库重放可能因变量未同步导致行为不一致
真正可用的是基于 **触发器执行栈深度** 的判断，但 MySQL 不暴露该信息；退而求其次，用唯一可追踪的上下文标识更稳妥。
推荐方案：用 UUID() + 临时表记录触发路径
核心思路是把“本次 SQL 语句的唯一性”作为递归锚点，而不是依赖易变的变量。实际操作分三步：
- 在触发器开头生成一次
UUID()，存入临时表（如temp_trigger_trace），并设UNIQUE KEY (trace_id) - 每次进入触发器前先查该
trace_id是否已存在；存在则说明是递归调用，直接LEAVE - 触发器结束前删掉该记录（或用
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(); <p>-- 尝试插入 trace_id，失败即说明已存在（递归） INSERT IGNORE INTO temp_trigger_trace (trace_id) VALUES (v_trace); IF ROW_COUNT() = 0 THEN LEAVE proc_exit; END IF;</p><p>-- 正常业务逻辑... IF NEW.status = 'active' THEN INSERT INTO user_log (user_id, action) VALUES (NEW.id, 'activated'); END IF;</p><p>DELETE FROM temp_trigger_trace WHERE trace_id = v_trace; END;
注意：temp_trigger_trace 必须是 ENGINE=MEMORY 或 TEMPORARY 表，避免事务锁表；且需在会话初始化时建好（不能在触发器里 CREATE TEMPORARY TABLE，MySQL 不允许）。
比变量更稳的替代：用触发器参数传状态位
如果触发器只用于特定业务入口（比如统一由某个存储过程调用），最干净的做法是根本不用“拦”，而是让调用方显式控制：
- 存储过程中加参数
IN p_skip_trigger BOOLEAN DEFAULT FALSE - 触发器里读取该参数（通过用户变量或新增字段暂存），决定是否跳过逻辑
- 关键点：所有非人工直连的 DML 都走这个存储过程，人工调试时才设
p_skip_trigger = FALSE
这比在触发器里猜“是不是递归”更可控——递归不是技术问题，是设计问题。一旦发现需要靠状态位兜底，应该回溯检查：这张表的变更是否真的必须由触发器驱动？能不能改成应用层事件监听或定时补偿？
真正难处理的从来不是怎么拦，而是哪些场景不该让它发生。触发器递归往往暴露了表设计耦合过紧、状态流转缺乏中心协调的问题。
