MySQL触发器无法安全可靠实现多表级联更新，因其内核级限制：一张表仅允许一个AFTER UPDATE触发器；禁止在触发器中更新原表；跨表更新须用带LIMIT 1的标量子查询，否则易报错或性能雪崩。
MySQL 触发器不能安全、可靠地实现多表级联更新逻辑——这不是写法问题，是内核级限制。想靠触发器自动同步 product.name 到 mobile_version.productname 和 auth_server_product.productname，大概率会遇到死锁、报错或数据不一致。
为什么 AFTER UPDATE 触发器里改不了原表
MySQL 5.7+ 明确禁止在触发器中对“当前 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。
- 这不是权限没开、也不是配置不对，是引擎层硬性限制，所有版本（包括 8.0）都如此
-
BEFORE UPDATE只能赋值给NEW.xxx，影响即将写入的行；AFTER UPDATE连读NEW.id都可以，但写就是不行 - 想自动维护时间戳、状态派生字段？必须用
BEFORE UPDATE SET NEW.updated_at = NOW()，别在触发器里再 UPDATE 自己
跨表更新只能指向“其他表”，且必须用标量子查询
真要联动更新子表，唯一合法路径是：在 product 表的 AFTER UPDATE 触发器里，UPDATE 或 INSERT 其他表（如 mobile_version），但语法和逻辑有强约束。
- 禁止写
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没索引，每次触发都全表扫描product，高并发下性能雪崩
一张表只能有一个 AFTER UPDATE 触发器
你不能为不同字段变更分别建多个 AFTER UPDATE 触发器。MySQL 要求每个 (table, timing, event) 组合唯一，重复定义会报错：same trigger event and action time already exists for this table。
- 所有联动逻辑（比如改
name同步到 A 表、改status记录日志、改price更新缓存）必须合并进同一个触发器，用IF OLD.xxx != NEW.xxx分支判断 - 注意
OLD.xxx和NEW.xxx都可能为NULL，直接比较会失效，得用IFNULL(OLD.xxx, '') != IFNULL(NEW.xxx, '') - 批量更新（如
UPDATE product SET name = 'xxx' WHERE category_id = 5影响 200 行）会让触发器执行 200 次，每轮都跑一遍子查询 —— 这比应用层一次 JOIN 更新慢一个数量级
真正该用什么替代触发器做级联更新
优先走应用层或定时任务发起一次性跨表更新，而不是让触发器兜底。MySQL 原生的 UPDATE ... JOIN 是最可控、可验证、可回滚的方式。
- 先用等效
SELECT验证影响范围：SELECT COUNT(*) FROM mobile_version mv JOIN product p ON mv.productid = p.id WHERE p.id IN (1,2,3) - 再执行原子更新：
UPDATE mobile_version mv JOIN product p ON mv.productid = p.id SET mv.productname = p.name WHERE p.id IN (1,2,3) - 若需多表同步，把多个
UPDATE包进同一事务：BEGIN; UPDATE ...; UPDATE ...; COMMIT; - 外键
ON UPDATE CASCADE仅限InnoDB+ 索引列，且只支持单层，复杂业务仍得靠应用层协调
触发器里最容易被忽略的点是：它不响应 INSERT IGNORE 或 REPLACE INTO 中被跳过的行，也不处理外键约束本身 —— 它只在“语句成功执行后”才运行，既不拦截非法数据，也不补救失败动作。
