MySQL触发器中禁止直接UPDATE、INSERT或DELETE触发它的表，因执行引擎在解析阶段即检测并报ERROR 1442，该限制与权限、语法、存储引擎、SQL模式无关，且无法绕过。
MySQL触发器里不能UPDATE、INSERT或DELETE触发它的那张表，不是语法写错了，也不是权限不够，而是执行引擎在解析阶段就直接拒绝——报ERROR 1442，没商量。
触发器执行时表已被“锁定上下文”
当你执行UPDATE users SET name = 'a' WHERE id = 1，MySQL会为users表注册一个“活跃表上下文”，包含表指针、锁模式和当前语句类型。触发器一启动，这个上下文就处于in_use状态。此时任何再指向users的DML语句（哪怕只是UPDATE users SET x=1 WHERE id = NEW.id）都会被内核检测到冲突，立刻中止。
- 这个检查发生在SQL解析阶段，不依赖事务隔离级别、存储引擎（InnoDB/MyISAM都生效）
-
SET SQL_LOG_BIN = 0、sql_safe_updates等开关完全无效 - 跨库写法如
UPDATE other_db.users照样被拦，判断依据是表名，不是库名
为什么连动态SQL和存储过程也绕不过
有人试过用PREPARE + EXECUTE拼出UPDATE语句，或把UPDATE封装进存储过程再CALL，结果还是ERROR 1442。因为预编译阶段就校验目标对象是否为“基表且未被当前上下文占用”，动态SQL只是延迟执行，不延迟校验；存储过程调用只是栈展开，不重置表上下文。
-
PREPARE stmt FROM 'UPDATE users ...'; EXECUTE stmt;→ 解析时就报错 -
CREATE PROCEDURE sp_update_users() BEGIN UPDATE users ... END;，再在触发器里CALL sp_update_users()→ 同样卡在1442 - 视图、临时表、CTE中隐式引用本表，只要最终DML目标是触发源表，一律拦截
BEFORE里该用SET NEW，而不是UPDATE
如果你只是想修正即将写入的数据（比如补时间戳、标准化字段、设默认状态），正确姿势是操作NEW伪记录，而不是发一条新UPDATE。
-
SET NEW.updated_at = NOW();✅ 修改的是内存中的待插入/更新行副本 -
UPDATE users SET updated_at = NOW() WHERE id = NEW.id;❌ 触发1442，哪怕表名写全、加了索引也没用 -
NEW在AFTER触发器中只读，赋值会静默失败或报错，这类逻辑只能放BEFORE - 涉及
NEW.xxx的拼接、计算、比较，必须先处理NULL：用IFNULL(NEW.email, '')或COALESCE(NEW.status, 'pending')
真要更新本表，只能解耦出触发器上下文
没有“安全又同步”的内置方案。所有绕过方式本质都是把写操作移出触发器栈：要么靠外部机制（应用层、EVENT），要么靠中间载体（临时表、日志表）。
- 临时表必须是
CREATE TEMPORARY TABLE，且需在触发器外创建（不能在触发器里执行CREATE TEMPORARY TABLE） - 中间表方案需配权限：EVENT或外部脚本要有目标表的UPDATE权限，且不能依赖
NEW（它在EVENT里不可用） - 外键
ON UPDATE CASCADE仅适用于简单一对一关联，且要求子表外键列有索引，不解决复杂业务逻辑 - 应用层统一包裹DML（如
BEGIN; INSERT ...; UPDATE ...; COMMIT;）是最可控路径，但要放弃“数据库自动兜底”的幻想
最容易被忽略的一点：这个限制不是“暂时没实现”，而是MySQL硬编码的执行模型——截至2026年6月，没有任何配置项、补丁或版本升级能关闭它。接受它，然后选合适的解耦路径，比纠结“为什么不能”更省时间。
