mysql触发器无法响应on delete cascade是innodb引擎层设计行为，因其直接物理删除子表行、不构造delete语句，故跳过sql层触发器；唯一可靠响应点是父表的before delete触发器。
MySQL 触发器根本不会响应 ON DELETE CASCADE 删除动作，这不是遗漏或配置错误，而是 InnoDB 引擎层绕过 SQL 层的确定行为。
ON DELETE CASCADE 为什么完全跳过子表触发器
外键级联删除由 InnoDB 在存储引擎层直接执行：它定位索引、物理删除子表行，全程不构造 DELETE FROM 语句。而触发器只在 SQL 层解析并执行 DML 语句时才被激活——没有 DELETE 语句，就没有触发器调用机会。
常见错误现象包括：
- 你在
order_items上定义了AFTER DELETE触发器用于更新统计表，但通过删orders触发级联后，统计值没变 -
SELECT * FROM information_schema.TRIGGERS能查到触发器，但它就是“静默” - 误以为是权限或语法问题，反复检查触发器定义，实际根本没进入执行路径
这个行为适用于所有约束驱动变更：ON UPDATE CASCADE、SET NULL、RESTRICT 等均不触发对应表的 INSERT/UPDATE/DELETE 触发器。
在父表建 AFTER DELETE 触发器手动删子表，能补上吗
不能真正“补上”，只会制造新问题。你写这样的逻辑：
CREATE TRIGGER orders_after_delete AFTER DELETE ON orders FOR EACH ROW DELETE FROM order_items WHERE order_id = OLD.id;
它确实会触发 order_items 的 DELETE 触发器，但代价是：
- 必须先禁用或删除原有外键（否则报错
ERROR 1452） -
AFTER触发器不参与事务回滚：若后续语句失败，orders行恢复，order_items却已永久丢失 - 失去外键的参照完整性保护，应用误操作可能留下孤儿数据
换句话说，你用触发器模拟级联，等于主动放弃外键最核心的价值。
真正可控的响应点只有父表的 BEFORE DELETE
如果你必须对“级联即将发生”做反应（比如记审计日志、发通知、预校验），唯一稳定入口是父表的 BEFORE DELETE 触发器，但它只能预判，不能监听结果：
- 用
SELECT COUNT(*) INTO @cnt FROM order_items WHERE order_id = OLD.id判断是否存在子项 - 可在此处写入
audit_log，标记“将删除订单 X 及其关联项” - 避免在其中调用含事务或锁的存储过程——MySQL 明确禁止触发器内开启事务，会直接报
ERROR 1305
注意：AFTER DELETE 里记录“已删除订单 X”也不代表子表清理完成，因为外键可能被临时禁用、或约束本身失效。
替代方案的实际取舍要点
想让每条子表变更都走触发器逻辑，只有两个落地路径：
- 彻底移除外键，把级联逻辑提到应用层：显式开启事务 →
DELETE FROM order_items WHERE order_id = ?→DELETE FROM orders WHERE id = ?→ 提交。好处是全链路可控、可重试、可加日志；坏处是所有业务代码都要遵守，漏一处就破防 - 保留外键 + 在子表
BEFORE DELETE加兜底校验：例如查SELECT 1 FROM orders WHERE id = OLD.order_id，不存在则SIGNAL SQLSTATE '45000'中断，防止产生孤儿数据
最容易被忽略的是：级联不触发触发器这件事，和 MySQL 版本、存储引擎配置、SQL_MODE 都无关——只要用原生 ON DELETE CASCADE，就必然如此。别在 trigger 定义或权限上浪费调试时间。
