MySQL触发器不支持递归调用，max_sp_recursion_depth对其完全无效；该参数仅控制存储过程/函数/事件的嵌套层级，触发器中修改原表会直接报错而非触发深度限制。
MySQL 触发器无法递归调用自己，max_sp_recursion_depth 对其完全无效。 你设成 100、1000 甚至 0，都拦不住触发器“想递归”——因为它压根就不支持这种行为。所谓“递归触发”，实际是误判了跨表链式调用或设计缺陷导致的死循环。
为什么 max_sp_recursion_depth 对触发器没用
这个参数只控制「存储过程/函数/事件」的嵌套调用层级（比如 A 调 B，B 调 C），不作用于触发器。官方文档和实测均确认：max_sp_recursion_depth 在触发器上下文中被忽略。即使你执行 SET GLOBAL max_sp_recursion_depth = 1，一个 AFTER UPDATE 触发器去改本表，依然会报错 Can't update table 't' in stored function/trigger because it is already used by statement which invoked this stored function/trigger，而不是深度超限。
-
max_sp_recursion_depth的生效范围明确排除触发器 - 试图在触发器里
CALL自身存储过程，再由该过程更新原表？仍会触发“同一语句中多次修改同表”的禁止规则 - 错误日志里如果看到
Too many levels of nesting，那一定是存储过程嵌套，不是触发器递归
常见误以为“触发器递归”的真实场景
多数人说的“触发器递归”，其实是以下几种可观察、可调试的链式行为，它们合法但容易失控：
-
AFTER UPDATE修改其他表other_table→ 触发other_table上的BEFORE/AFTER触发器 → 再改第三张表……形成跨表跳转（MySQL 允许，最多 16 层链式，受max_sp_recursion_depth间接限制） - 同一张表上多个触发器（如
BEFORE INSERT和AFTER INSERT）共存，但它们彼此不触发；若BEFORE改了 NEW 字段，AFTER读到的是已改值，容易引发逻辑错觉 - 应用层反复执行同一条 SQL（比如监听状态字段变更后主动重查+更新），被当成“数据库自己在循环”
- 未加判断地在
AFTER触发器里执行UPDATE t SET x = ... WHERE id = NEW.id—— 这会直接报错，不是递归，是 MySQL 的硬性禁止
真正能落地的“类递归”替代方案
如果业务确实需要级联刷新（如组织树路径、库存锁定传递、状态逐级上报），必须绕开触发器自调用幻想，用显式控制代替隐式依赖：
- 在源头 UPDATE 前，先写入一个标记字段，例如
UPDATE t SET updating_cascade = 1, status = 'pending' WHERE id = 123 - 触发器中加条件：
IF OLD.updating_cascade != 1 THEN ... END IF;，避免被链路下游再次触发 - 级联逻辑改由应用层发起：触发器只做轻量动作（如
INSERT INTO event_queue (table_name, row_id, action) VALUES ('t', NEW.id, 'cascade_update')） - 后台服务轮询
event_queue，按需执行最多 N 层更新，并记录日志、设置超时、支持人工干预
最易被忽略的一点：MySQL 触发器没有“调用栈”概念，也没有 CALLER() 或 TRIGGER_DEPTH() 这类元信息函数。你无法在触发器里知道自己是第几跳——这决定了任何“动态判断深度”的尝试都是徒劳的。老老实实用标记字段 + 应用层队列，才是可控、可观测、可运维的正解。
