ERROR 1442是MySQL引擎级硬拦截，非配置或版本问题；它在语法解析阶段扫描AST，只要DML目标表名与触发源表名一致即拒绝执行，BEFORE中仅SET NEW合法，AFTER中任何同表DML均报错。
ERROR 1442 是引擎级硬拦截，不是配置或版本问题
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，不是你写错了 SQL，也不是没开某个开关——这是 InnoDB 和 MyISAM 在解析阶段就做的静态检查，从 5.7 到 8.4 全部强制生效。
它不运行你的语句，只扫描 AST（抽象语法树），只要发现 DML 目标表名和触发源表名一致，立刻拒绝。哪怕你加了 WHERE id = NEW.id、用了 ON DUPLICATE KEY UPDATE、甚至把 UPDATE 包进存储过程再 CALL，照样报错。
这不是死锁，也不是事务隔离导致的“查不到刚改的行”，而是执行栈保护：防递归调用、防数据不一致，内核层就掐断。
BEFORE 中 SET NEW.xxx 是唯一合法的“修改当前行”方式
想改即将插入或更新的那行数据？只能在 BEFORE INSERT 或 BEFORE UPDATE 里用 SET NEW.column = value。
-
SET NEW.created_at = NOW()✅ 安全，改的是内存副本 -
UPDATE users SET status = 'pending' WHERE id = NEW.id❌ 立刻触发 ERROR 1442 -
SET NEW.phone = (SELECT normalized FROM phone_clean WHERE raw = NEW.phone)✅ 子查询只读，合法 -
SET NEW.id = 123❌ 主键字段不可赋值，MySQL 直接拒绝 -
NEW在AFTER触发器中只读，赋值不报错但无效
临时表不能在触发器里建，必须提前创建
网上常见错误是写 CREATE TEMPORARY TABLE tmp_xxx 在触发器里——MySQL 会直接报错，因为 DDL 不被允许。
正确做法是：
- 由应用初始化脚本、连接池首次建连时，或 DBA 手动执行
CREATE TEMPORARY TABLE tmp_order_sync (id BIGINT PRIMARY KEY, new_status VARCHAR(20)) - 触发器中只做
INSERT INTO tmp_order_sync SELECT NEW.id, 'processed' - 真正更新原表交给外部机制：MySQL
EVENT定时扫描，或应用层轮询消费tmp_order_sync并执行UPDATE orders - 临时表名建议带业务前缀（如
tmp_user_last_login），避免多服务共用会话时冲突
跨表操作可行，但主从复制下链式行为不成立
在 users 表的触发器里写 INSERT INTO orders，然后 orders 上的触发器也执行了——这不是“触发器调用了另一个触发器”，而是 MySQL 在执行完那条 INSERT 后，自动检查并拉起目标表上匹配的触发器。
关键限制只针对“触发它的那张表”，所以：
-
INSERT INTO other_db.audit_log✅ 完全合法 -
UPDATE users❌ 即使加库名UPDATE mydb.users也报错 - 主库上
users → orders → logs链路跑通，但从库只重放原始语句，orders和logs的变更都是主库直写 binlog 的，从库上的对应触发器根本不会执行
最容易被忽略的一点：这个限制不看逻辑是否“安全”，只看表名是否重复。哪怕你用 SELECT ... INTO @var 查本表，在某些旧版本也会触发 ERROR 1442，因为解析器已识别出对本表的引用。
