避免触发器死循环的关键是防止其修改自身监听的表，可通过条件判断、使用BEFORE触发器修改NEW值、利用中间表解耦或移至应用层处理。例如仅在特定字段变化时执行操作，并设置max_sp_recursion_depth限制递归深度，结合日志监控确保逻辑正确。
MySQL触发器在执行过程中，如果操作本身又触发了另一个触发器，甚至再次触发自身，就可能引发死循环。这类问题通常出现在AFTER或BEFORE类型的触发器中，尤其是在对同一张表进行增删改操作时。避免死循环的关键在于合理设计逻辑、控制触发条件以及利用数据库机制。
理解触发器死循环的产生原因
当一个触发器在执行过程中修改了它所监听的表，就会再次触发该触发器，从而形成无限递归。例如：
- 在
users表上定义了一个AFTER UPDATE触发器； - 该触发器内部执行
UPDATE users SET ... WHERE id = X;； - 这个更新操作会再次触发
AFTER UPDATE，导致重复执行； - 若无终止条件，将陷入死循环。
MySQL默认允许有限的递归（受max_sp_recursion_depth限制），但超过层级会报错，并非真正解决循环问题。
使用条件判断控制触发逻辑
最直接的方式是在触发器内部加入判断逻辑，避免不必要的重复操作。
比如：只在特定字段被修改时才执行后续动作：
CREATE TRIGGER trg_after_update_users
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.status != NEW.status THEN
-- 只有status变化时才执行额外更新
UPDATE log_table SET update_time = NOW() WHERE user_id = NEW.id;
END IF;
END;
这样可以防止因无关字段更新而误触发连锁操作。
避免在触发器中直接修改原表
如果必须更新数据，考虑以下替代方案：
- 使用应用程序层处理：将原本放在触发器中的逻辑移到应用代码中统一控制流程；
- 通过中间表解耦：把需要“间接更新”的信息写入临时表或日志表，再由事件调度器（Event Scheduler）或外部脚本处理；
-
用BEFORE触发器修改NEW值：如果是INSERT或UPDATE前的数据调整，应使用
BEFORE类型并修改NEW.column，而不是重新执行SQL语句。
启用递归限制与监控
MySQL提供了参数来限制存储过程和触发器的递归深度：
SET GLOBAL max_sp_recursion_depth = 8;
此设置可防止无限嵌套，但只是安全兜底，并不能根除设计缺陷。建议结合日志分析和测试验证触发器行为。
另外，可通过开启通用查询日志（general_log）观察实际执行的SQL序列，排查是否出现重复调用。
基本上就这些。关键是别让触发器自己改自己盯的表，加判断、拆逻辑、用NEW/OLD对象，就能避开大多数坑。
