MySQL的AFTER UPDATE触发器不能更新原表，因内核级硬限制报ERROR 1442；唯一合法方式是BEFORE UPDATE中SET NEW字段，或在AFTER中更新其他关联表实现级联。
MySQL 的 AFTER UPDATE 触发器不能更新它自己所依附的表，但可以安全更新其他关联表——这是实现级联更新的合法路径。绕不开这个限制，就只能报错 ERROR 1442。
为什么 AFTER UPDATE 触发器里不能改原表
MySQL 明确禁止在触发器中对“当前 SQL 正在操作的那张表”执行任何写操作（INSERT/UPDATE/DELETE）。哪怕只是想用 UPDATE my_table SET updated_at = NOW() WHERE id = NEW.id，也会直接失败。
- 错误信息固定为：
Can't update table 'my_table' in stored function/trigger because it is already used by statement which invoked this stored function/trigger - 这不是权限问题，也不是配置没开，是 MySQL 内核级硬限制（5.7+ 和 8.0 均如此）
- 想改原表字段？唯一可行方式是
BEFORE UPDATE中赋值NEW.xxx；AFTER阶段连读NEW.id都没问题，但写就是不行
AFTER UPDATE 级联更新必须指向另一张表
真正能落地的级联逻辑，一定是“主表更新 → 触发器去改子表”。比如 orders 表更新状态后，同步刷新 order_items 的状态字段。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 子表更新语句要明确指定条件，避免全表扫描：
UPDATE order_items SET item_status = NEW.status WHERE order_id = NEW.order_id - 如果子表有外键约束（如
FOREIGN KEY (order_id) REFERENCES orders(order_id)），确保ON UPDATE CASCADE没被禁用，否则可能因约束冲突中断 - 批量更新风险：若一次
UPDATE orders SET status = 'shipped' WHERE user_id = 123影响 500 行，触发器会执行 500 次子查询 —— 这时应考虑是否该用应用层批量处理替代
跨表更新别用 JOIN，用子查询取单值
触发器里不支持 UPDATE t1 JOIN t2 ON ... SET t1.x = t2.y 这类语法，会报错或解析失败。必须把关联逻辑收进子查询，并保证只返回一个值。
- 正确写法：
SET NEW.user_level = (SELECT level FROM users u WHERE u.id = NEW.user_id LIMIT 1) -
LIMIT 1是必须的，否则遇到多匹配直接报错：Subquery returns more than 1 row - 子查询性能敏感：如果
users表没在id上建索引，每次触发都可能拖慢主 SQL - 不要在子查询里调用自定义函数或复杂表达式，MySQL 触发器对函数调用支持有限，且难以调试
注意 IGNORE/REPLACE 不触发 AFTER UPDATE
如果你的业务用了 UPDATE IGNORE 或 REPLACE INTO，要特别小心：它们在字段冲突时会跳过更新，导致 AFTER UPDATE 触发器完全不执行。
-
REPLACE INTO实际是DELETE + INSERT，它触发的是BEFORE DELETE和BEFORE INSERT，跟UPDATE触发器无关 - 想兜底处理？统一改用
INSERT ... ON DUPLICATE KEY UPDATE，它一定触发BEFORE INSERT，冲突时也走AFTER INSERT（MySQL 8.0.19+ 支持） - 如果非用
IGNORE不可，联动逻辑必须移到应用层，靠affected_rows判断是否真实发生了变更
最常被忽略的一点：触发器没有独立事务，也不支持 COMMIT 或 ROLLBACK。主 SQL 回滚，触发器里的所有操作也一起回滚；主 SQL 成功，触发器逻辑才真正落库。别指望在触发器里做“半成功”补救。
