MySQL触发器递归报错主因是默认禁用递归及隐式提交语句（如CREATE、TRUNCATE等），调max_sp_recursion_depth治标且有死循环风险；应优先用标记字段或梳理依赖图规避递归。
MySQL 触发器递归调用报错，本质是触发器在执行过程中又间接或直接触发了自身（比如 AFTER INSERT 触发器里又执行 INSERT），而 MySQL 默认禁止这种行为——不是因为逻辑错误，而是出于安全与栈溢出防护。关键解法确实是调整 max_sp_recursion_depth，但直接改它往往治标不治本，甚至埋下死循环隐患。
为什么设置 max_sp_recursion_depth 后仍报错 ERROR 1422: Explicit or implicit commit is not allowed in stored function or trigger
这个错误常被误认为是递归深度问题，其实它和事务隐式提交强相关：MySQL 不允许在触发器内执行会引发隐式提交的语句（如 CREATE TABLE、ALTER TABLE、TRUNCATE、LOCK TABLES，甚至某些存储过程里的 INSERT ... SELECT 在特定引擎下也会触发）。此时哪怕把 max_sp_recursion_depth 设为 255，照样报错。
- 检查触发器 SQL 中是否含上述禁用语句，尤其是
INSERT INTO ... SELECT涉及非事务表（如MyISAM）时 - 确认当前存储引擎是否为
InnoDB（推荐），避免混合引擎操作 - 用
SHOW VARIABLES LIKE 'storage_engine';和SHOW CREATE TABLE核对表引擎
如何安全地修改 max_sp_recursion_depth
该变量控制存储过程/触发器最大嵌套调用层数，默认为 0（禁止任何递归）。设为非零值需同时满足运行时生效 + 持久化配置，否则重启后失效。
- 临时生效（当前会话无效，仅对新连接起作用）：
SET GLOBAL max_sp_recursion_depth = 10; - 永久生效：在
my.cnf或my.ini的[mysqld]段添加：max_sp_recursion_depth = 10，然后重启 MySQL - 注意：该变量不能动态设为 0 以外的值再回设为 0 来“关闭”——设为 0 就彻底禁用所有递归，包括合法的跨触发器调用
- 值不宜过大（如 > 100），否则可能耗尽线程栈空间，导致
Stack overflow或连接异常中断
比调参更可靠的替代方案：用标记字段规避递归
绝大多数所谓“需要递归触发”的场景，实际只需避免重复响应同一类变更。比起放宽递归限制，用业务层标记更稳定、可读性更强。
- 在目标表加一个
TINYINT(1) DEFAULT 0字段，例如is_trigger_handled - 触发器开头加判断：
IF NEW.is_trigger_handled = 1 THEN LEAVE proc_label; END IF; - 在触发器末尾更新该字段：
UPDATE tbl SET is_trigger_handled = 1 WHERE id = NEW.id; - 若需下游再次触发（如日志同步），可在应用层显式重置该字段，而非依赖触发器链式调用
真正难处理的从来不是参数上限，而是触发器间缺乏调用边界——一个 BEFORE UPDATE 改了字段，另一个 AFTER UPDATE 又监听该字段，稍不留神就形成闭环。与其反复调 max_sp_recursion_depth，不如先画出触发器依赖图，砍掉非必要链路。
