mysql触发器中update本表必报error 1442，是innodb/myisam引擎在sql解析阶段硬拦截的限制；唯一合法操作是在before insert/update中set new.column = value，其余任何dml（含子查询、临时表创建、存储过程调用）均被禁止。
MySQL触发器里UPDATE本表立刻报ERROR 1442
这不是配置问题、不是版本差异、也不是权限没开——是InnoDB和MyISAM引擎在SQL解析阶段就硬拦截的限制。只要触发器体里出现UPDATE t、INSERT INTO t或DELETE FROM t（哪怕加了WHERE id = NEW.id），MySQL连执行都不让，直接抛出ERROR 1442 (HY000): Can't update table 't' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。
常见误判包括：
- 以为“只改一行”就安全 → 错。MySQL不看逻辑，只比对表名是否命中
- 以为
INSERT ... ON DUPLICATE KEY UPDATE能绕过 → 错。它只触发BEFORE INSERT和AFTER INSERT，但你在AFTER里再UPDATE t，照样1442 - 以为用临时表或子查询就能躲开 → 错。子查询里若含
UPDATE或INSERT，整个触发器失效；CREATE TEMPORARY TABLE也不能在触发器内执行
BEFORE中SET NEW是唯一合法的“改本表”方式
SET NEW.column = value之所以能用，是因为它不产生新DML语句，只是修改即将写入的行副本。这发生在主语句执行前，不触发表锁重入，也不引发新事件。
必须注意的边界条件：
- 只能在
BEFORE INSERT或BEFORE UPDATE里用，AFTER中赋值无效（不报错但不生效） - 不能改主键字段（如
NEW.id），哪怕它是普通INT，MySQL也会拒绝 -
BEFORE INSERT时NEW.id还没生成（AUTO_INCREMENT为NULL），拿它拼业务码会出错 - 类型要匹配：给
NEW.phone赋超长字符串，可能截断或报错（取决于sql_mode）
为什么AFTER里更新同表会递归？
AFTER触发器执行时，原语句已提交，但表仍处于“活跃使用中”状态。此时任何对本表的DML都会再次申请写锁，内核判定为潜在递归起点，直接拒绝。
典型踩坑写法：
-
AFTER UPDATE ON users里写UPDATE users SET updated_at = NOW() WHERE id = NEW.id→ 立刻1442 -
BEFORE UPDATE里设了NEW.status = 'done'，然后AFTER里又去UPDATE users→ 第二次触发又进BEFORE/AFTER，链式调用 - 在触发器里调用存储过程，而该过程内部偷偷
UPDATE users→ 同样被拦，不看调用深度
max_sp_recursion_depth只是调试开关，设成1能暴露链路，但不能修复逻辑。
真要同步更新，得换思路
想实现“订单完成 → 更新用户最后下单时间”，不能在orders的触发器里直接UPDATE users。可行路径只有三条：
- 应用层做：主SQL完成后，由业务代码发第二条
UPDATE（最干净，但需控制并发） - 中间表+EVENT：触发器写
INSERT INTO tmp_user_update，再由MySQL事件每秒拉取并更新（延迟毫秒到秒级） - 关联表触发：在
users表上建触发器，监听orders的状态变更字段（比如加个last_order_id标志），再反向更新
所有方案都绕不开一个事实：MySQL触发器的“本表写入”能力仅限于NEW字段预设。一旦超出这个范围，就不再是语法问题，而是架构选择问题。
