不能替代，因ON DELETE CASCADE是引擎原生原子操作，而触发器为用户逻辑、不参与事务回滚且易引发死锁或数据不一致。
MySQL触发器能替代外键级联删除吗？
不能直接替代，但可以模拟行为。外键的 ON DELETE CASCADE 是原子性、事务安全、引擎原生支持的；而触发器是用户定义逻辑，不参与外键约束检查，也不保证跨表操作的回滚一致性。如果你的表已有外键且启用了级联，别用触发器覆盖它——冲突会导致错误或数据不一致。
DELETE触发器里怎么安全删关联记录？
必须显式写 DELETE FROM 语句，并注意 WHERE 条件与主表行严格对应。常见错误是漏掉 OLD.id 或误用 NEW（DELETE 触发器中 NEW 为 NULL）：
CREATE TRIGGER del_user_profile AFTER DELETE ON users FOR EACH ROW DELETE FROM profiles WHERE user_id = OLD.id;
- 用
AFTER DELETE而非BEFORE：避免主表行还没删就被子表逻辑干扰 - WHERE 必须基于
OLD字段，且字段类型、值要完全匹配（比如user_id是BIGINT，就别传字符串进去） - 如果子表有外键指向主表，先禁用外键检查（
SET FOREIGN_KEY_CHECKS = 0）再删——但这会绕过所有外键约束，慎用
多个关联表时触发器容易踩哪些坑？
嵌套触发、顺序错乱、性能崩塌是最常见的三个问题：
- 触发器内删 A 表 → 触发 A 的 DELETE 触发器 → 又删 B 表 → 再触发 B 的触发器……形成无限递归。MySQL 默认限制最大嵌套深度为 25，超限报错
ERROR 1406 (HY000): Data too long for column（实际是栈溢出伪装） - 没控制执行顺序：比如用户删了
orders，触发器删order_items，但order_items的触发器又去删inventory_logs，而日志表有唯一索引冲突，整个事务就卡住 - 单条
DELETE FROM users WHERE id = 123可能触发 3 个触发器、执行 5 次 DELETE，IO 和锁开销陡增；高并发下容易锁表
什么场景下才该考虑用触发器做级联删除？
仅当满足全部以下条件时才值得尝试：
- 数据库已存在大量历史数据，且主外键关系混乱，无法安全添加或修改外键
- 业务逻辑复杂，比如“删用户时只删近30天的订单，旧订单转为归档状态”，这种没法靠
ON DELETE CASCADE实现 - 你有能力在应用层统一拦截所有
DELETE操作，确保不会绕过触发器直删主表（否则数据就残了）
真要用，务必在触发器开头加注释说明依赖链，并在子表上建好对应字段的索引——user_id 没索引的话，删一条用户可能扫全表 profiles。
