MySQL 5.7触发器中禁止直接DML自身表，因引擎层硬拦截导致ERROR 1442；仅允许BEFORE中修改NEW.*字段，AFTER中不可赋值；临时表须预建且仅作中转，更新需由外部机制（如Event或应用轮询）分批完成，并配幂等补偿。
MySQL 5.7 中触发器里直接 UPDATE、INSERT 或 DELETE 自身表，一定会触发 ERROR 1442。这不是配置问题，也不是权限或事务隔离级别能绕过的——它是 InnoDB 和 MyISAM 引擎在语句解析阶段就硬拦截的限制。
为什么 SET NEW.col 在 BEFORE 触发器里能用，但 UPDATE orders 就不行？
因为 SET NEW.col = value 是对“当前正在插入/更新的那行数据”的预设值修改，不产生额外 DML 语句，也不触发表锁重入；而 UPDATE orders SET ... WHERE id = NEW.id 是一条独立的 DML，会再次申请对 orders 表的写锁，此时表已在主语句上下文中被标记为“活跃使用中”，内核直接拒绝。
-
BEFORE INSERT/UPDATE只允许改NEW.*字段，不能查/写其他行（哪怕加了WHERE id = NEW.id） -
AFTER类型连NEW.*都不可赋值，只能做记录、发通知、写临时表 - 哪怕你加了
IF OLD.status != NEW.status判断，只要触发器体里出现任何对本表的 DML，1442 就立刻报
CREATE TEMPORARY TABLE 必须提前建，不能在触发器里执行
很多初学者在触发器开头写 CREATE TEMPORARY TABLE tmp_queue (...) ，结果触发器创建失败：MySQL 不允许在触发器内部执行 DDL。临时表必须由应用初始化脚本、连接池首次建连时，或 DBA 手动执行一次建好。
- 临时表名要唯一且带业务标识，比如
tmp_order_status_sync，避免多服务共用会话时冲突 - 结构至少包含主键（如
id INT PRIMARY KEY）和待更新字段（如new_status VARCHAR(20)） - 推荐加
ENGINE=MEMORY，比默认磁盘临时表快 3–5 倍，尤其适合高频小批量中转 - 不要依赖
IF NOT EXISTS——它在临时表场景下无效，重复建会报错，得靠外部逻辑保证只建一次
触发器只负责“记下来”，后续更新必须交给外部机制
临时表只是中转站，它的生命周期随会话结束自动销毁，所以不能指望它长期存数据。真正更新原表的操作，必须脱离触发器上下文。
- 用 MySQL Event 定时扫描：每 5 秒跑一次
process_pending_updates()存储过程，从tmp_queue读 ID 批量更新原表，再TRUNCATE tmp_queue - 应用层轮询更可控：比如订单服务监听到有新记录进
tmp_queue，就主动发起一次UPDATE orders SET ... WHERE id IN (...) - 严禁在存储过程中再调用触发器监听的表——否则又形成闭环，1442 可能变成隐式死锁
- 分批处理很重要：单次更新超 1000 行容易锁表，建议用
WHERE id BETWEEN ? AND ?分片
最容易被忽略的一点是：临时表方案不是“一劳永逸”，它把问题从“语法禁止”转移到了“时序一致性”。如果应用崩溃或事件调度器停摆，tmp_queue 里的数据就丢了——所以关键业务必须搭配幂等更新和补偿机制，不能只靠触发器+临时表闭环。
