MySQL触发器中禁止更新触发它的表，因此模拟外键级联更新时只能操作关联表（如orders），不能修改主表（如users）自身；BEFORE UPDATE更适合SET NULL等场景；触发器无法替代外键的约束能力，且存在并发、性能和调试难题。
触发器里不能直接更新触发它的表
MySQL 触发器执行时，如果尝试在 AFTER UPDATE 或 BEFORE UPDATE 中对**同一张表**做 UPDATE，会报错：Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger. 这是 MySQL 的硬性限制，不是权限或配置问题。
所以「用触发器模拟外键级联更新」必须绕开这个坑：
- 被更新的主表（如
users）只能在触发器里读取，不能写 - 真正要级联更新的必须是**另一张关联表**（如
orders），且该表不能是当前 SQL 正在修改的目标表 - 如果想改
users自身字段再同步到子表，得拆成两步：先改users，再由触发器去改orders
BEFORE UPDATE 比 AFTER UPDATE 更适合模拟 SET NULL
比如你希望当 users.status 变为 'inactive' 时，把所有关联的 orders.user_status 设为 NULL。这时用 BEFORE UPDATE 能提前拿到旧值和新值，逻辑更可控：
CREATE TRIGGER update_orders_on_user_status
BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.status != 'inactive' AND NEW.status = 'inactive' THEN
UPDATE orders SET user_status = NULL WHERE user_id = OLD.id;
END IF;
END;
注意点：
-
OLD.status和NEW.status必须显式比较，不能只看NEW.status—— 否则每次更新都会触发 - 这里用
UPDATE是安全的，因为orders不是触发器所在表 - 如果
orders.user_id没有索引，这条UPDATE会全表扫描，大表慎用
触发器无法替代外键的约束能力
外键能阻止非法数据写入（比如插入一个不存在的 user_id），而触发器做不到这点 —— 它只能在数据进来之后“补救”，没法拦截。
常见误操作：
- 以为加了触发器就等于有了外键，结果往
orders插了个不存在的user_id，触发器不触发，脏数据进来了 - 用触发器去“修复”缺失的父记录，比如自动插入一条默认
users，这会让业务语义混乱 - 没考虑并发：两个事务同时更新同一条
users记录，可能造成orders被重复更新或漏更新
真要强一致性，还是得靠外键；触发器只适合补位那些外键不支持的操作（比如跨库、跨表结构、或需要复杂条件判断的更新）。
性能和调试成本比想象中高
触发器是隐式执行的，不会出现在主 SQL 里，出问题时很难定位。比如某次 UPDATE users 变慢，你得想到去查有没有触发器、它里面有没有慢查询、有没有锁表。
几个实际影响：
- 每个触发器都会增加语句执行时间，哪怕只是简单赋值；10 万行批量更新时，触发器开销会被放大
- MySQL 5.7+ 不支持在触发器里调用存储过程（除非是
DEFINER权限足够），容易卡在权限报错ERROR 1442 - 备份还原时，触发器默认不导出（
mysqldump --triggers要显式加），上线后发现逻辑丢失很常见
真正难的从来不是写触发器，而是确认它在所有边界场景下都只执行一次、不干扰主流程、不拖慢吞吐——这些往往得靠线上日志和压测才能暴露。
