触发器不能替代外键级联删除，但能模拟其行为；mysql原生foreign key的on delete cascade最安全高效，触发器仅适用于myisam表、无法修改表结构或需额外逻辑等特殊场景。
触发器不能替代外键级联删除，但能模拟行为
MySQL 的 FOREIGN KEY 本身支持 ON DELETE CASCADE，这是最安全、最高效的方式。用触发器实现级联删除是绕过外键约束的“补救方案”，常见于 MyISAM 表（不支持外键）、或已有表无法修改结构、或需要在删除前执行额外逻辑（如日志记录、权限校验）的场景。直接写 AFTER DELETE 触发器做级联，容易漏掉事务一致性、循环触发、性能崩坏等问题。
为什么不能只写 AFTER DELETE 触发器
AFTER DELETE 触发器在父记录已删完后才执行，此时子表中关联数据若仍存在，就会变成“孤儿记录”——这违背了级联删除的语义。真正要模拟级联，必须在父记录删除前清理子数据，所以应优先考虑 BEFORE DELETE；若坚持用 AFTER DELETE，就得靠额外手段（如临时表、标记字段）兜底，复杂度陡增。
- MyISAM 表不支持外键，
BEFORE DELETE触发器是唯一可控入口 - InnoDB 表已有外键时，再建触发器可能引发冲突：
ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger -
AFTER DELETE中对同一库其他表执行DELETE，若子表也定义了AFTER DELETE触发器，可能触发嵌套调用甚至死循环
正确写法：用 BEFORE DELETE 触发器手动删子记录
以 orders（主表）和 order_items（子表）为例，假设没有外键，需在删 orders 时自动删对应 order_items：
DELIMITER $$ CREATE TRIGGER trg_delete_order_items BEFORE DELETE ON orders FOR EACH ROW BEGIN DELETE FROM order_items WHERE order_id = OLD.id; END$$ DELIMITER ;
关键点：
- 必须用
OLD.id（不是NEW.id），因为DELETE没有新值 - 子表删除语句必须明确加
WHERE条件，避免误删全表 - 如果子表有二级子表（如
item_logs），这个触发器不会自动递归处理，得在子表上再建一层触发器 - 无事务保护：若子表删除失败（如被锁、磁盘满），整个
DELETE会回滚（InnoDB 下），但 MyISAM 不支持事务，失败后父记录已删，子记录残留
比触发器更稳的替代方案
除非业务强要求绕过外键，否则别碰触发器级联：
- 改用 InnoDB + 原生外键：
ALTER TABLE order_items ADD CONSTRAINT fk_order_id FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE CASCADE; - 应用层统一处理：在 ORM 或 DAO 层先查子记录 ID 列表，再批量删子表、再删主表（注意控制批量大小，防锁表）
- 用存储过程封装逻辑，显式开启事务、捕获异常、加重试，比触发器更易测试和调试
触发器像后台静默脚本，出问题难定位；外键约束和应用层逻辑才是可读、可测、可维护的正路。真要用触发器，务必在测试环境压测并发删除场景，观察锁等待和死锁日志。
