MySQL禁止在AFTER UPDATE触发器中更新原表，仅允许BEFORE UPDATE修改NEW值；跨表更新须用带LIMIT 1的标量子查询；单表仅容一个AFTER UPDATE触发器；主键级联更新应优先用ON UPDATE CASCADE。
MySQL 里用触发器做多表级联更新，不是“写法对不对”的问题，而是根本走不通的路——内核禁止，硬性限制，强行上会出死锁、报错、数据不一致。
为什么 AFTER UPDATE 触发器里不能 UPDATE 原表
MySQL 5.7+（包括 8.0）明确禁止在触发器中对当前 SQL 正在操作的那张表执行任何写操作。哪怕只写一句 UPDATE product SET updated_at = NOW() WHERE id = NEW.id，也会立刻报错：Can't update table 'product' in stored function/trigger because it is already used by statement。
这不是权限或配置问题，是引擎层锁定机制决定的。你只能在 BEFORE UPDATE 中给 NEW.xxx 赋值；AFTER UPDATE 连读 NEW.id 都可以，但写就是不行。
- 想自动维护时间戳？必须用
BEFORE UPDATE SET NEW.updated_at = NOW() - 想根据字段变化记录日志？可以用
AFTER UPDATE插入日志表，但别碰原表 - 想改完主表再改子表？可以，但必须确保子表更新逻辑不反向触发原表
跨表更新只能靠标量子查询，且必须加 LIMIT 1
真要在 product 表更新后同步 mobile_version.productname，唯一合法路径是：在 product 的 AFTER UPDATE 触发器里，用子查询更新其他表。
错误写法：UPDATE mobile_version JOIN product ON ... —— 触发器里不支持 JOIN 语法，直接解析失败。
正确写法：UPDATE mobile_version SET productname = (SELECT name FROM product p WHERE p.id = mobile_version.productid LIMIT 1) WHERE productid = NEW.id。
- 子查询必须加
LIMIT 1，否则遇到多行匹配会中断触发器，报错Subquery returns more than 1 row -
product.id必须有索引，否则每次触发都全表扫描，高并发下性能雪崩 - 如果
mobile_version.productid没索引，WHERE 条件也会慢成瓶颈
一张表只能有一个 AFTER UPDATE 触发器
MySQL 要求每个 (table, timing, event) 组合唯一。你不能为 “改 name 同步 A 表” 和 “改 status 记录日志” 分别建两个 AFTER UPDATE 触发器，重复定义会报错：same trigger event and action time already exists for this table。
所有联动逻辑必须合并进同一个触发器，用 IF 判断字段是否真的变了：
- 用
IF OLD.name != NEW.name判断字段变更，但注意NULL比较会失效 - 稳妥写法是
IF (OLD.name IS NULL) != (NEW.name IS NULL) OR OLD.name != NEW.name - 多个字段分支要嵌套清晰，避免漏判或误判
真正该用外键 ON UPDATE CASCADE 的地方，别硬上触发器
如果你只是想让子表的外键字段随主表主键变更而自动更新（比如 orders.order_id 改了，order_details.order_id 自动跟着改），直接用外键约束更安全、高效：
FOREIGN KEY (order_id) REFERENCES orders(order_id) ON UPDATE CASCADE。
触发器适合的是外键做不到的事：比如跨库同步、非外键字段联动、复杂条件判断、写日志、调用函数等。但只要涉及“主键变更 → 子表外键字段变更”，优先走 ON UPDATE CASCADE，别绕弯。
最常被忽略的一点：触发器里的 SQL 是事务的一部分，一旦子查询报错（比如子表没数据、字段类型不匹配），整个原始 UPDATE 会回滚。你以为只影响联动逻辑，其实连主表更新都失败了。
