触发器不能替代ON UPDATE CASCADE——因其非原子操作、易引发死锁或报错，无法保证外键完整性及多级联更新一致性，且MySQL禁止在触发器中更新已使用表。
不能用触发器替代外键级联更新逻辑——MySQL 触发器无法安全、可靠地模拟 ON UPDATE CASCADE 行为，尤其在并发或事务复杂场景下极易出错或死锁。
为什么触发器不能替代 ON UPDATE CASCADE
外键级联是存储引擎（InnoDB）原生支持的原子操作，而触发器是用户定义的 SQL 逻辑，二者底层机制完全不同：
-
ON UPDATE CASCADE在事务内由引擎自动执行，保证一致性；触发器里若尝试更新被触发的表（如主表更新后想再改自己），MySQL 5.7+ 直接报错：Can't update table 't1' in stored function/trigger because it is already used by statement... - 触发器无法感知外键约束的完整性检查时机，比如你手动
UPDATE主键后，子表外键值可能已违反约束但尚未报错，触发器却已执行了错误补救 - 多层级联（A→B→C）用触发器会陷入嵌套调用，InnoDB 默认禁止触发器递归，且难以控制执行顺序和回滚边界
想同步更新关联字段？优先用 UPDATE JOIN，不是触发器
业务上常见的“主表 product.name 改了，mobile_version.productname 和 auth_server_product.productname 也要同步”这类需求，不该靠触发器兜底，而应明确由应用层或定时任务发起一次性的跨表更新：
- 写法必须是
UPDATE mobile_version mv JOIN product p ON mv.productid = p.id SET mv.productname = p.productname WHERE p.id IN (1,2,3) - 务必加
WHERE条件限制范围，否则全表扫——先用等效SELECT验证影响行数 - 若需原子性，把多个
UPDATE包进同一个事务；不要指望单个触发器覆盖所有路径 - 避免在触发器里写
UPDATE ... JOIN ... SET other_table.x = ...：虽语法允许，但一旦 other_table 有外键指向当前表，就可能触发约束冲突或死锁
真要用触发器做联动？只限 BEFORE + NEW 赋值
触发器唯一安全的“干预”方式，是在 BEFORE UPDATE 中修改 NEW 值，例如自动刷新时间戳或派生字段：
-
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 product SET id = 100 WHERE id = 1 这种主键变更发生时，所有依赖它的外键引用必须一致生效——只有 ON UPDATE CASCADE 能做到这点；触发器做不到，也不该让它做。
