MySQL触发器不支持递归，硬编码限制最多间接递归1层；max_sp_recursion_depth对其无效；应通过标记字段+条件判断规避，或改用应用层队列/定时任务。
MySQL 触发器递归调用默认是禁用的，max_sp_recursion_depth 不影响触发器
很多人以为调大 max_sp_recursion_depth 就能控制触发器递归深度，其实这是个常见误解。该变量只对存储过程、函数、事件中的嵌套调用生效，对触发器完全无效。MySQL 从 5.7 开始就硬编码限制了触发器最多只能“间接”递归 1 层——也就是 A 触发器修改某行 → 触发 B 触发器 → B 再改同一张表的同一行 → 此时会直接报错 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger 或更常见的 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 压根不支持真正的触发器递归，所谓“限制深度”，其实是“禁止深度 > 1”。想靠配置参数放开递归，走不通。
真正可行的规避方式：用临时标记字段 + 条件判断
如果业务逻辑确实需要“类似递归”的行为（比如级联更新上级状态、树形结构路径刷新），得绕过 MySQL 的限制，自己做控制。核心思路是加一个显式的标记字段（如 updating_cascade TINYINT(1) DEFAULT 0），并在触发器开头检查它。
- 所有涉及级联更新的触发器第一行必须写：
IF NEW.updating_cascade = 1 THEN LEAVE proc_label; END IF; - 执行级联操作前，先用
UPDATE ... SET updating_cascade = 1 WHERE ...标记源头变更；级联完成后，再设回 0 - 注意：这个字段不能被业务代码直接写入，否则会破坏控制逻辑；建议加注释并加权限限制
- 如果用的是 JSON 字段存路径或层级，更新时也得同步把这个标记带上，避免触发器误判
INSERT/UPDATE/DELETE 触发器行为差异直接影响是否“看起来像递归”
同一个表上多个触发器（比如 BEFORE UPDATE 和 AFTER UPDATE）不会互相触发，但它们对同一行的修改可能引发其他表的触发器，进而形成跨表链式反应。这种链式调用容易被误认为“递归”，实际是 MySQL 允许的（只要不违反“同一语句中不能多次修改同表”规则）。
-
BEFORE触发器里修改NEW值，不会再次触发自身，但会影响后续的AFTER触发器读到的数据 -
AFTER触发器里执行UPDATE other_table，会正常触发other_table上的对应触发器——这是安全的，也是唯一能构造多跳联动的方式 - 最危险的是在
AFTER UPDATE里又去UPDATE same_table：哪怕加了 WHERE 条件，只要命中了刚被主语句修改过的行，大概率报ERROR 1442
替代方案比硬扛触发器更可靠：应用层队列 or 定时任务
一旦触发器逻辑开始变复杂（比如要查多张表、调 API、处理异常分支），就该考虑撤出数据库。触发器天生不适合做协调型任务——它没有事务外重试、无法记录完整上下文、出错后难以定位。
- 把“需要级联的动作”写成轻量消息，投递到 Redis 队列或 Kafka，由单独 worker 消费执行
- 对实时性要求不高的场景，直接记日志表（如
pending_cascade_tasks），用EVENT每分钟扫一次批量处理 - 如果非要用触发器兜底，至少加上
INSERT INTO debug_log (...) VALUES (...)，否则出问题时连哪条数据卡住都不知道
触发器不是不能用，而是它的容错边界非常窄。那个看似简单的 UPDATE 语句，背后可能藏着锁等待、死锁、主从延迟放大、甚至备份时被忽略的隐式逻辑——这些都不会在 SHOW CREATE TRIGGER 里写出来。
