mysql 8.0触发器中禁止任何对本表的dml操作，执行即报error 1442，属内核级硬限制；唯一允许的是before触发器中修改new字段，其余如update/insert/delete本表、间接写入或调用含dml的存储过程均会触发该错误。
MySQL 8.0 触发器执行时报“递归调用错误”，根本不是真发生了递归，而是数据库直接拦下了任何对本表的写操作——报错 ERROR 1442 是硬性保护，不是配置没开、也不是深度不够。
为什么触发器里 UPDATE 本表一定报 ERROR 1442
这是 MySQL 内核级限制，发生在语句执行阶段，与事务隔离级别、binlog 格式、锁状态都无关。只要触发器代码中出现 UPDATE tbl、INSERT INTO tbl 或 DELETE FROM tbl（哪怕只改一行、哪怕用子查询包装），就会立刻中断并抛出：Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。
常见误判点：
- 以为调用存储过程就能绕过 → 实际上只要该过程内部写了本表，照样报错
- 以为
SELECT ... FOR UPDATE只是加锁 → 某些隔离级别下它也会被拦截 - 以为
INSERT IGNORE或REPLACE INTO算“非更新” → 它们本质仍是 DML，全部被禁 - 去查
max_sp_recursion_depth参数 → 这个变量对触发器完全无效
哪些写法看似安全但其实也踩雷
很多开发者试图用间接方式绕过，结果仍失败。关键在于：MySQL 拦截的是“执行路径中是否可能再次激活当前触发器”，而不是“当前 SQL 是否显式写了本表”。
以下操作全部触发 ERROR 1442：
- 在
BEFORE INSERT中给NEW.field赋值后，又执行UPDATE t SET x = y WHERE id = NEW.id - 通过视图（定义为
SELECT * FROM t）执行INSERT INTO v，而视图底层触发器再去写t - 在触发器中写临时表
tmp_t，再用INSERT INTO t SELECT * FROM tmp_t - 用
JSON_TABLE解析数据后，再把结果INSERT INTO t
注意：SET SQL_LOG_BIN = 0 只影响复制日志，不解除该限制；RECURSIVE_TRIGGERS 是 SQL Server 的参数，MySQL 根本没有这个配置项。
真正能落地的三种绕过方式
没有“开启递归”的开关，只有把写操作移出触发器上下文。选哪种取决于你对实时性、一致性和运维复杂度的容忍边界。
-
异步消息解耦：触发器里只写一条记录到
event_queue表，或调用sys_exec()发 Kafka / Redis Stream 消息；由独立消费者进程拉取后执行真实UPDATE—— 延迟毫秒~秒级，适合非强实时场景 -
应用层统一处理：把原本想塞进触发器的逻辑，提到业务代码中，用单事务包裹
INSERT+ 后续UPDATE—— 一致性最强，但要求所有写入口可控 -
运行时标记跳过：在触发器开头加
IF @disable_self_trigger IS NULL OR @disable_self_trigger = 0 THEN ... END IF，并在应用层执行前设SET @disable_self_trigger = 1—— 简单但易漏，需全链路约定
最常被忽略的一点：即便你用 BEFORE 触发器修改 NEW 字段（如自动填充 created_at），只要后续没再发 DML，就不会触发 ERROR 1442 —— 这是唯一被 MySQL 明确认可的“本表变更”，但仅限于行级修正，不能用于跨行关联更新。
