MySQL触发器中对本表执行DML操作会直接报ERROR 1442，因解析时即拦截；唯一安全修改是BEFORE中SET NEW；绕过需用中间表、应用层事务或会话变量跳过。
MySQL 触发器里只要出现对本表的 UPDATE、INSERT 或 DELETE，立刻报 ERROR 1442——这不是“可能递归”，而是语法级拦截；所谓“避免递归”，本质是绕开这个硬限制，而不是等它循环起来再拦。
为什么 AFTER 触发器里写 UPDATE 同表必报 ERROR 1442
MySQL 在解析触发器体时就检查目标表名，只要和触发源表一致，直接拒绝执行。哪怕你加了 WHERE id = NEW.id、用了子查询、或封装进存储过程，都无效。
-
BEFORE触发器中用SET NEW.col = ...是唯一安全的“改本表”方式，不触发新事件 -
AFTER触发器里任何 DML 操作（包括INSERT INTO same_table）都会触发拦截 - 跨库操作如
UPDATE other_db.users同样危险：如果other_db.users上也有触发器，且它反向操作当前表，照样报错或卡死 -
INSERT ... ON DUPLICATE KEY UPDATE只激活BEFORE INSERT和AFTER INSERT，不会走UPDATE类触发器——但如果你在AFTER INSERT里又去UPDATE本表，还是崩
max_sp_recursion_depth = 1 不是修复方案，是调试开关
这个变量只能在会话级设置：SET SESSION max_sp_recursion_depth = 1，它让 MySQL 在第二层递归调用时直接报错，用来暴露问题链路，但不能替代逻辑修正。
- 值设为
0（不限制）等于放弃防护；设为2仍可能在第三层崩溃，且无法预判边界 - 该变量对存储过程也生效——如果触发器里调用了含
UPDATE的 SP，同样被拦 - 连接池场景（如
pymysql）必须每次获取连接后重置，否则复用旧连接可能残留max_sp_recursion_depth = 0或2 - 不能在触发器体内写
SET—— MySQL 语法不允许
真正能落地的三种绕过方式
核心思路是把“对本表的写操作”移出触发器上下文，交给可控机制执行。
- 用中间表解耦：
INSERT INTO trigger_queue (table_name, pk, action) VALUES ('users', NEW.id, 'update')，再由外部脚本或事件调度器消费并执行真实更新 - 应用层统一处理：把原来塞在触发器里的逻辑（如同步状态、记日志）挪到业务代码中，用一个事务包裹
INSERT+UPDATE，既保证一致性，又彻底规避数据库限制 - 运行时标记跳过：在业务 SQL 执行前设会话变量
SET @skip_my_trigger = 1，触发器开头加IF @skip_my_trigger IS NOT NULL THEN LEAVE proc_label; END IF;；注意执行完要清理SET @skip_my_trigger = NULL，否则同连接后续语句也被跳过
恢复数据时别信 max_sp_recursion_depth，得关触发器逻辑
用 mysqldump 恢复时，每条 INSERT 都会激活触发器，而触发器里若有 UPDATE users SET updated_at = NOW() 这类逻辑，直接撞上 ERROR 1442。
- 恢复前执行：
SET SESSION sql_log_bin = 0+SET @TRIGGER_DISABLED = 1 - 所有触发器定义中统一加守卫：
IF @TRIGGER_DISABLED IS NOT NULL THEN LEAVE proc_label; END IF; - 不要删触发器——误删无法回退，且恢复中途失败会导致状态不一致
-
sql_log_bin = 0还能防止 binlog 记录触发器副作用，避免从库同步异常
最易被忽略的是跨表/跨库链路的隐式闭环：你以为只改了日志表，结果日志表的触发器又调了函数，函数里悄悄 UPDATE 回原表。排查时得顺藤摸瓜，查清所有被间接调用的函数、视图、事件是否碰了原表。
