MySQL触发器中禁止直接UPDATE同表是InnoDB/MyISAM引擎级限制，为避免递归和死锁；主流绕过方案是CREATE TEMPORARY TABLE中转数据，再由EVENT或外部逻辑分步更新，且临时表须会话级隔离。
MySQL 触发器里不能 UPDATE 同一张表？这是引擎级限制
MySQL 的 BEFORE 或 AFTER 触发器中直接 UPDATE 当前表会报错：ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger. 这不是语法写错了，是 InnoDB（和 MyISAM）为避免递归和死锁做的硬性约束——触发器执行时，原表已被语句加锁并处于“正在修改”状态，不能再被触发器自己二次修改。
临时表是绕过它的主流解法，但得注意：不是所有临时表都管用，必须是 CREATE TEMPORARY TABLE，且只在当前会话可见、事务结束后自动销毁。
用 CREATE TEMPORARY TABLE 中转数据，再分步更新
核心思路是把需要更新的行 ID（或完整字段）先捞出来存到临时表，退出触发器上下文后再操作原表。这相当于把“触发器内更新”拆成“触发器记录 + 外部脚本/事件更新”，但如果你必须在数据库端闭环，就得靠临时表+存储过程组合。
- 临时表必须在触发器外显式创建（比如在应用启动时或初始化脚本中），
CREATE TEMPORARY TABLE不能放在触发器内部执行（会报错） - 临时表结构要和你要更新的目标列对齐，至少包含主键或唯一标识字段（如
id）和待更新值（如status） - 触发器里只做
INSERT INTO temp_table SELECT id, new_status FROM ...，不碰原表 - 真正更新交给定时任务、应用层轮询，或另一个监听该临时表的事件（MySQL 5.7+ 可用
EVENT，8.0+ 支持更稳）
示例：想在插入订单后，把对应用户 user_id 的 last_order_time 更新为当前时间：
CREATE TEMPORARY TABLE tmp_user_update ( user_id INT PRIMARY KEY, update_time DATETIME );
然后在 AFTER INSERT ON orders 触发器里：
INSERT INTO tmp_user_update (user_id, update_time) SELECT NEW.user_id, NOW() ON DUPLICATE KEY UPDATE update_time = VALUES(update_time);
替代方案对比：事件（EVENT）比存储过程更可控
如果坚持纯数据库侧闭环，EVENT 比手动调用存储过程更可靠——它不依赖外部调用，也不受触发器上下文限制，还能控制执行延迟（比如 DO SLEEP(0.1) 避开锁竞争）。
-
EVENT默认以 DEFINER 权限运行，需确保该用户有对目标表的UPDATE权限 - 不要设太短的间隔（如
EVERY 1 SECOND），频繁查临时表可能拖慢性能；建议用ON SCHEDULE EVERY 5 SECOND+DO块里加IF EXISTS(SELECT 1 FROM tmp_user_update)判断 - 每次
EVENT执行完记得清空临时表：TRUNCATE tmp_user_update，否则重复更新
注意：EVENT 在 MySQL 中默认关闭，需确认 event_scheduler = ON（查 SHOW VARIABLES LIKE 'event_scheduler';）
PostgreSQL 和 SQL Server 完全没这问题？别轻信
PostgreSQL 的触发器允许在 BEFORE 中修改 NEW 行（即改即将插入的数据），也支持 AFTER 中发通知或调用函数去更新同表——但它靠的是 MVCC 和更细粒度的锁机制，不是“放开限制”。SQL Server 的 INSTEAD OF 触发器也能绕过，但逻辑要重写。
- 跨数据库迁移时，别直接照搬 MySQL 临时表方案；PG 可用
NOTIFY+ 监听进程，SQL Server 更倾向用INSTEAD OF或合并到业务逻辑 - 哪怕在 MySQL 里，如果只是想改
NEW字段（比如插入时自动补created_at），用BEFORE INSERT就够了，根本不需要临时表 - 最易忽略的一点：临时表名在不同连接间不冲突，但如果你用连接池（如 PHP 的 mysqli_pconnect 或 Python 的 SQLAlchemy pool），可能多个请求共用一个会话，导致临时表数据混杂——此时应加会话级前缀或改用普通表 + 时间戳清理
