mysql触发器中禁止直接update、insert或delete自身表，解析阶段即报error 1442；唯一合法修改方式是在before触发器中赋值new字段，且不可改主键。
MySQL 触发器里 UPDATE、INSERT 或 DELETE 当前表，根本不是“递归执行后报错”，而是语法解析阶段就直接拦截，强制抛出 ERROR 1442 —— 这不是递归错误，是硬性禁止。
为什么一写 UPDATE 就立刻报 ERROR 1442
MySQL 内核在触发器体被解析时，就扫描所有 SQL 片段，只要发现目标表名和触发器所属表一致（哪怕只是 UPDATE users SET name = 'x' WHERE id = NEW.id），立即终止编译并报错：Can't update table 'users' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。它不运行、不判断条件、不看是否只改一行，纯静态表名匹配。
- 子查询里嵌套
UPDATE或调用含 DML 的存储过程 → 同样报错 -
INSERT ... ON DUPLICATE KEY UPDATE不会触发 UPDATE 类触发器，但你在它的AFTER INSERT里再UPDATE users→ 照样 1442 - 用临时表、视图、JOIN 都绕不开，因为限制发生在 AST 解析层，不是执行层
SET NEW.column = value 是唯一合法的“修改本表”方式
只有在 BEFORE INSERT 或 BEFORE UPDATE 中对 NEW 赋值，才是 MySQL 明确认可的写法。它不生成新 DML，只是修改即将写入的行副本，不触发表锁重入，也不引发事件链。
- 必须在
BEFORE类型中使用，AFTER中赋值不生效（也不报错） - 不能改主键字段（如
NEW.id），MySQL 会拒绝，哪怕它是普通 INT - 类型要严格匹配：给
NEW.phone赋超长字符串，可能截断或报错（取决于当前sql_mode） -
NEW字段可读可写，OLD只读；BEFORE INSERT时NEW.id是NULL（若为 AUTO_INCREMENT），拿它拼业务码会出错
所谓“绕过递归”的常见方案，其实全是移出触发器上下文
没有真正的“同步绕过”。所有可行方案本质都是把写操作从触发器内剥离，交给外部机制处理：
- 建预置临时表（如
tmp_order_sync），触发器里只做INSERT INTO tmp_order_sync SELECT ...，再由EVENT或应用轮询消费 - 触发器里写 Kafka / Redis Stream / 文件，由独立消费者进程执行后续
UPDATE - 加标记字段（如
is_processing TINYINT DEFAULT 0），在触发器开头检查：IF NEW.is_processing = 1 THEN LEAVE proc_label; END IF;，再由应用层控制写入时机 - 用会话变量（如
@trigger_disabled := 1）做开关，但注意连接池场景下每次取连接后需重置
最容易被忽略的是：max_sp_recursion_depth 对触发器完全无效，RECURSIVE_TRIGGERS 这个配置项 MySQL 根本不存在——别浪费时间搜它。真正卡住你的，从来不是深度，是那道连语法树都没让过的第一道门。
