MySQL外键级联删除不触发子表DELETE触发器是设计行为，非bug；因ON DELETE CASCADE属约束自动清理，不构造DELETE语句，故跳过触发器执行链，且该行为同样适用于ON UPDATE CASCADE。
MySQL外键级联删除不触发DELETE触发器是设计行为，不是bug
MySQL明确文档规定：由ON DELETE CASCADE引发的子表行删除，**不会执行该子表上定义的任何BEFORE DELETE或AFTER DELETE触发器**。这不是存储引擎（InnoDB）的“限制”，而是SQL标准兼容性与执行模型决定的——级联动作属于约束检查阶段的自动清理，绕过了DML语句生命周期，自然跳过触发器链。
为什么InnoDB不给级联操作发触发器信号
InnoDB把ON DELETE CASCADE当作约束机制的一部分，而非用户发起的SQL语句。它在主表记录标记为“待删”后，直接遍历索引定位子表行并物理删除，全程不构造DELETE FROM ...语句，因此不满足触发器的触发条件（即“某条DELETE语句执行”）。这带来两个关键事实：
- 哪怕你在子表
order_items上写了AFTER DELETE触发器用于更新统计表，当orders被级联删时，这个触发器完全静默 -
SHOW CREATE TABLE看到的ON DELETE CASCADE，和你手写DELETE FROM order_items WHERE order_id = ?，对触发器来说是两种完全不同的执行路径 - MyISAM根本不支持外键，所以这个问题只存在于InnoDB；但即便换引擎，只要用原生级联，触发器就不可见
想让级联也走触发器逻辑？只能绕开原生级联
没有配置开关能打开“级联触发触发器”功能。可行替代路径只有两种：
- 放弃
ON DELETE CASCADE，改用orders表上的AFTER DELETE触发器手动删order_items，但必须接受它不参与事务回滚（前文已强调） - 彻底移除外键，把级联逻辑全移到应用层：显式开启事务 →
DELETE FROM order_items WHERE order_id = ?→DELETE FROM orders WHERE id = ?→ 提交，这样每步都可控、可加日志、可重试 - 若必须保留外键约束（如防止应用误操作），可在子表触发器里加兜底校验：比如
BEFORE DELETE中查SELECT 1 FROM orders WHERE id = OLD.order_id，不存在则报错中断，避免产生孤儿数据
容易被忽略的细节：级联删除也不触发INSERT/UPDATE触发器
同理，ON UPDATE CASCADE更新子表字段时，子表的BEFORE UPDATE或AFTER UPDATE触发器同样不会运行。这点常被误认为“只DELETE有问题”。真实情况是：**所有由约束驱动的自动变更（CASCADE、SET NULL、NO ACTION等）均不激活触发器**。如果你依赖触发器维护审计日志、缓存失效或搜索索引，就必须确认这些变更是否真由应用SQL发起——否则日志会漏掉一大块。
