MySQL触发器根本禁止递归，ERROR 1442和1422是语法级硬拦截，max_sp_recursion_depth对其完全无效；真正可行方案是用标记字段（如is_cascade_pending）配合条件判断规避，而非调参。
MySQL 触发器根本不会因为“递归层数超限”而崩溃——它压根就不允许递归，连第一层都拦在门外。所谓“递归层数限制”是误读，max_sp_recursion_depth 对触发器完全无效，系统崩溃也绝非该变量导致。
为什么触发器报 ERROR 1442 或 ERROR 1422，不是深度问题
这两个错误的本质是 MySQL 的硬性执行保护机制：
-
ERROR 1442（Can't update table 'xxx' in stored function/trigger...）：触发器试图修改自己所属的表，哪怕只是UPDATE t SET x = 1 WHERE id = NEW.id，也会被立即拒绝——这不是栈溢出，是语法执行阶段拦截 -
ERROR 1422（Explicit or implicit commit is not allowed...）：触发器里执行了隐式提交语句，如TRUNCATE、CREATE TABLE、LOCK TABLES，或INSERT INTO ... SELECT涉及 MyISAM 表——这和递归无关，只和事务隔离规则冲突 -
max_sp_recursion_depth只影响存储过程/函数的嵌套调用链，对触发器上下文不生效；设成 0 或 100，结果一样：直接报错，不走深度判断逻辑
哪些操作会让人误以为“触发器在递归”
实际中常见几种被当成“递归”的链式行为，它们合法但容易失控：
- 同一张表上
BEFORE UPDATE和AFTER UPDATE共存：前者改NEW字段，后者读到已改值，逻辑错觉像“自调用” - 跨表触发：AFTER INSERT on
orders→ UPDATEinventory→ 触发inventory的 AFTER UPDATE → 再 UPDATEwarehouse，形成多跳链路（MySQL 允许，但需确保每跳都不碰原表） - 应用层循环：业务代码监听字段变更后，主动发起新一轮 UPDATE，被日志误判为“数据库自动循环”
- 未加防护的级联更新：AFTER UPDATE 触发器里无条件执行
UPDATE parent SET updated_at = NOW() WHERE id = NEW.parent_id，若 parent 表也有同类型触发器，就会触发 ERROR 1442
真正能落地的规避方案：标记字段 + 显式控制
别调 max_sp_recursion_depth，它对触发器没用。要用业务可控的方式绕开限制：
- 在目标表加一个
is_cascade_pending TINYINT(1) DEFAULT 0字段，并加注释说明“仅用于触发器防重入” - 所有相关触发器开头加判断：
IF NEW.is_cascade_pending = 1 THEN LEAVE proc_label; END IF; - 业务端需要级联时，先
UPDATE t SET is_cascade_pending = 1, status = 'updating' WHERE id = ?，再执行主变更 - 触发器完成级联逻辑后，显式清空标记：
UPDATE t SET is_cascade_pending = 0 WHERE id = NEW.id; - 禁止应用代码直接写
is_cascade_pending字段，可通过列权限或触发器前置校验拦截
系统崩溃的真实诱因和应对点
如果真出现崩溃（如 mysqld 进程退出、CPU 100%、连接大量超时），大概率不是触发器“递归太深”，而是以下更危险的问题：
- 触发器里执行了大范围
UPDATE或SELECT ... INTO OUTFILE，锁表时间过长，拖垮整个实例 - 多个触发器叠加写同一个中间表（如
event_log），且没建索引，导致 INSERT 堆积、binlog 延迟飙升 - 用
INSERT INTO ... SELECT从大表拉数据进临时表，触发器未加LIMIT或WHERE条件，一次扫千万行 - 误把
cte_max_recursion_depth设得过大（如 100000），配合无终止条件的 WITH RECURSIVE 查询，吃光内存
这类问题不会报 ERROR 1442，但会让 MySQL 失去响应。查 slow log、SHOW PROCESSLIST 和 error log 中的 stack trace 才是关键。
