MySQL触发器不会自动递归调用。默认严格禁止任何直接或间接修改本表的操作，否则报ERROR 1442，本质是执行栈保护机制，防止无限嵌套；绕过需将本表修改移出触发器上下文。
MySQL 触发器会自动递归调用吗？
不会。MySQL 默认完全禁止触发器的递归调用，哪怕语句看起来“间接”触发了自身——只要触发器内修改了本表，且该操作又满足同一触发器的激活条件，就会直接报错 ERROR 1442 (HY000)。
这是 MySQL 的硬性限制，不是配置开关能绕过的。它发生在执行时（runtime），与存储过程中的递归逻辑完全不同。
-
BEFORE INSERT中更新本表 → 报错 -
AFTER UPDATE中再UPDATE本表 → 报错 - 哪怕通过临时表、视图或存储过程封装，只要最终 SQL 修改了触发器所属表，仍被拦截
为什么 ERROR 1442 是“无法更新存储引擎”的误导性提示？
错误信息里写的 Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger，容易让人误以为是锁或事务问题，其实本质是 MySQL 的**执行栈保护机制**：防止无限嵌套、状态不可控、日志写入混乱。
这个限制也适用于函数（DETERMINISTIC 函数里也不能改表），但和触发器不同，函数报错更早（解析阶段就拒绝）。
- 不是并发问题，单线程执行也会触发
- 不是隔离级别导致，
READ COMMITTED或SERIALIZABLE都一样 - 不是 binlog 格式影响，
ROW/MIXED下均生效
绕过递归限制的可行路径有哪些？
没有“开启递归”的配置项，只能换思路。核心原则是：**把对本表的修改，从触发器上下文中移出去**。
- 用
INSERT ... SELECT+ 临时表暂存中间结果，再由外部应用或定时任务批量回写 - 在触发器中写入
events表或消息队列（如 Kafka、RabbitMQ），由独立消费者处理后续更新 - 改用应用层逻辑：把原本想在触发器里做的关联更新，提到业务代码中，用事务包裹多个
UPDATE - 极少数场景可用
SET @trigger_disabled = 1+ 条件判断跳过，但必须确保所有入口统一检查，极易出错，不推荐
DELIMITER $$
CREATE TRIGGER t1_after_insert
AFTER INSERT ON orders
FOR EACH ROW
BEGIN
IF @trigger_disabled IS NULL OR @trigger_disabled = 0 THEN
-- 正常逻辑
INSERT INTO order_logs (order_id, action) VALUES (NEW.id, 'created');
END IF;
END$$
DELIMITER ;替代方案里最容易踩坑的是什么？
最常见的是误以为「用存储过程封装 UPDATE 就能绕开」——不行。只要存储过程在触发器内被调用，且过程体里有对本表的 DML，照样触发 ERROR 1442。
另一个高危操作是依赖 INSERT DELAYED（已废弃）或 INSERT IGNORE 试图“静默”规避，它们不改变触发器执行上下文，限制依然生效。
真正安全的边界只有一条：触发器代码执行流结束前，不能有任何语句（含间接调用）修改当前表。
