MySQL触发器无法安全替代ON UPDATE CASCADE，因引擎禁止更新当前表、无法感知约束时机、多级联会触发递归限制；合法用途仅限BEFORE中赋值NEW字段或标量子查询派生值。
MySQL 里无法用触发器安全实现主外键强制级联更新——这不是写法问题，是引擎硬性限制，强行绕开只会埋下死锁、数据不一致或报错的坑。
为什么 ON UPDATE CASCADE 不能用触发器替代
外键的 ON UPDATE CASCADE 是 InnoDB 存储引擎原生支持的原子操作，在事务内由引擎自动执行；而触发器是用户 SQL 逻辑，二者机制完全不同：
-
Can't update table 't1' in stored function/trigger because it is already used by statement—— MySQL 5.7+ 明确禁止在触发器中更新当前正被修改的表，哪怕只写一句UPDATE t1 SET x = NOW() WHERE id = NEW.id都会直接报错 - 触发器无法感知外键完整性检查的真实时机，可能在约束校验前就改了子表，导致脏数据残留
- 多层级联（A→B→C）会触发嵌套调用，InnoDB 默认禁用递归触发器，且无法保证回滚边界一致
哪些触发器操作是合法但危险的
虽然语法上允许某些跨表写入，但实际使用极易出问题：
- 在
AFTER UPDATE ON product中写UPDATE mobile_version SET name = (SELECT name FROM product p WHERE p.id = mobile_version.productid LIMIT 1)—— 必须加LIMIT 1，否则多行匹配直接中断触发器 - 子查询若没走索引（比如
product.id缺少主键或唯一索引），每次触发都全表扫描product，高并发下性能雪崩 - 一张表只允许一个
AFTER UPDATE触发器，所有联动逻辑（同步字段、记日志、刷新缓存）必须塞进同一个触发器，靠IF OLD.x != NEW.x分支判断，且要注意NULL比较失效问题
真正能安全用的触发器场景只有两种
触发器唯一稳妥的用途，是改即将写入的行本身，而不是去动别的表：
-
BEFORE UPDATE中赋值给NEW.updated_at或NEW.status：比如SET NEW.updated_at = NOW()，合法、无副作用 - 用标量子查询派生字段：
SET NEW.status = (SELECT status FROM users u WHERE u.id = NEW.user_id LIMIT 1)—— 要求子查询绝对单值、响应快、有索引支撑 - 禁止在触发器里出现任何
UPDATE t1、INSERT INTO t1、DELETE FROM t1，哪怕目标表和当前表只是外键关联，也可能破坏约束链
业务上需要“改 A 就同步 B/C”，该怎么做
别依赖触发器兜底，应由应用层或定时任务主动发起一次性跨表更新：
- 用
UPDATE JOIN写法：UPDATE mobile_version mv JOIN product p ON mv.productid = p.id SET mv.productname = p.name WHERE p.id IN (1,2,3) - 务必先用等效
SELECT验证影响行数，避免误扫全表 - 若需强一致性，把多个
UPDATE包进同一事务，而不是指望单个触发器覆盖所有路径 - 如果业务真要求“立刻同步”，说明模型设计可能有问题——主表字段被高频修改还要求下游实时一致，通常意味着该字段不该放在主表，或应引入缓存/消息队列解耦
最常被忽略的一点：触发器里的逻辑永远无法覆盖所有数据变更入口。比如通过 LOAD DATA INFILE、REPLACE INTO、或跳过触发器的备份恢复操作，都会让触发器失效。所谓“强制级联”，在 MySQL 触发器层面根本不存在可靠实现路径。
