MySQL触发器禁止递归执行，ERROR 1422是硬性限制，max_sp_recursion_depth对触发器无效；需用中间表+异步处理绕过，或移交应用层控制逻辑。
MySQL 触发器递归执行被拒绝：ERROR 1422
触发器里改自己监听的表，MySQL 默认直接报 ERROR 1422（“Explicit or implicit commit is not allowed in stored function or trigger”），根本不是深度不够的问题——它压根不让你递归。真正控制递归层数的，是全局变量 max_sp_recursion_depth，但它只对存储过程、函数生效，对触发器完全无效。
也就是说：max_sp_recursion_depth 设再大，也无法让触发器“合法递归”。触发器的递归行为本身就被 MySQL 禁止，除非你绕过它的检测逻辑。
想让触发器“看起来像递归”，只能靠间接更新
常见做法是用临时表、内存表或外部表做中转，把本该直接更新原表的操作，改成先写入中间表，再由另一个触发器或定时任务/事件去消费。这样就避开了“当前触发器修改当前表”的硬限制。
- 在
AFTER INSERT触发器里，不要写UPDATE target_table SET ...，而是写INSERT INTO temp_update_queue (...) VALUES (...) - 另建一个
EVENT或用应用层轮询temp_update_queue，批量处理后再清空 - 确保中间表引擎为
MEMORY或InnoDB，避免锁表或事务冲突 - 注意：
INSERT ... SELECT从原表查数据再插到中间表，不算“修改原表”，不会触发新一层触发器
max_sp_recursion_depth 的真实作用和坑点
这个变量只影响存储过程/函数内部调用自身（或互相调用）的嵌套层数，默认是 0（禁止任何递归）。设成 10 就最多允许 10 层调用链。但它跟触发器无关，也跟触发器触发的其他过程是否递归无关——只要那个过程没主动调用自己，max_sp_recursion_depth 就不介入。
- 设置命令必须带
GLOBAL：SET GLOBAL max_sp_recursion_depth = 10 - 会话级设置无效：
SET SESSION max_sp_recursion_depth = 10不起作用 - 重启 MySQL 后失效，需写入配置文件
my.cnf的[mysqld]段：max_sp_recursion_depth = 10 - 值过大可能引发栈溢出或死循环，尤其在没有终止条件的递归函数里
替代方案：用应用层控制逻辑深度更可靠
数据库层强行模拟递归，容易失控。实际项目中，更推荐把多层联动逻辑收回到应用代码里，用明确的循环或队列控制执行次数和边界。
- 触发器只做轻量通知（如写日志、发消息到 Redis 队列）
- 应用监听队列，按业务规则决定是否继续更新、更新几次、何时退出
- 能加日志、埋点、熔断、重试——这些在纯 SQL 里几乎没法调试
- MySQL 8.0+ 的
atomic DDL和触发器稳定性仍不如应用层可控
触发器的递归限制不是配置问题，是设计约束。绕开它不难，但真要靠它实现复杂流程，迟早掉进不可观测的执行黑洞里。
