on delete cascade 不触发子表 delete 触发器，因级联由 innodb 引擎层直接执行，绕过 sql 层；唯一可靠响应点是父表的 before/after delete 触发器。
ON DELETE CASCADE 会跳过被引用表的 DELETE 触发器
MySQL 明确规定：当父表记录被删除、触发外键 ON DELETE CASCADE 自动清理子表行时，**子表上的 DELETE 触发器完全不会执行**。这不是 bug，是引擎层的设计选择——级联操作由存储引擎（InnoDB）直接完成，绕过了 SQL 层的触发器机制。
常见错误现象：
- 你在
order_items表上定义了BEFORE DELETE触发器，用于记录删除日志或校验依赖； - 但当
orders表中某条订单被删，order_items中关联行确实消失了，日志表却空空如也； -
SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'order_items' AND EVENT_MANIPULATION = 'DELETE'能查到触发器，但它就是不响。
为什么不能靠“在父表建触发器”来补救
有人尝试在父表（如 orders）上建 AFTER DELETE 触发器，手动删子表并期望借此“激活”子表触发器——这行不通。因为：
-
AFTER DELETE ON orders里执行DELETE FROM order_items WHERE order_id = OLD.id，这只是普通 DML，它确实会触发order_items的 DELETE 触发器； - 但此时你已绕开了外键级联，等于自己实现了级联逻辑，而外键约束本身（包括
ON DELETE CASCADE）必须被禁用或移除，否则会报错ERROR 1452（违反外键约束）； - 更关键的是：
AFTER触发器不参与事务回滚——如果后续语句失败，父表记录恢复，子表数据却已永久丢失。
真正能响应级联动作的唯一位置：父表的 BEFORE/AFTER DELETE
如果你必须对“级联删除发生”这件事做反应（比如同步更新统计表、发通知、写审计日志），唯一可靠入口是父表自身的触发器，且只能靠预判或事后验证：
- 在
orders的BEFORE DELETE中，用SELECT COUNT(*) INTO @cnt FROM order_items WHERE order_id = OLD.id检查是否有子项，再决定是否写日志或调用存储过程； - 在
orders的AFTER DELETE中，可安全执行INSERT INTO audit_log (...) VALUES (OLD.id, 'order_deleted_with_cascade', NOW())，但这只是记录“父行删了”，不代表子行一定被删干净（外键可能失效或被禁用）； - 避免在触发器里调用含事务或锁的存储过程，MySQL 禁止在触发器中开启事务，否则直接报错
ERROR 1305（PROCEDURE does not exist）或隐式提交失败。
调试时最容易忽略的静默失效点
级联删除 + 触发器不执行，常被误判为“触发器没生效”，其实问题根本不在触发器本身：
- 执行
SHOW WARNINGS后什么都没有？说明触发器压根没被调用，不是内部出错； - 确认外键定义里真写了
ON DELETE CASCADE，而不是ON DELETE RESTRICT或漏写； - 检查子表触发器是否被意外
DISABLE（MySQL 8.0+ 支持，但低版本不识别该语法，DISABLE 实际无效）； - 用
SELECT @@foreign_key_checks确保没被临时关掉——关掉后级联行为消失，但也不会报错，只会留下孤儿数据。
外键级联和触发器是两套平行机制，一个在引擎层跑，一个在 SQL 层跑，它们不握手、不通知、不协同。想让它们“配合”，就得放弃其中一方的自动化，把控制权收回到应用层或显式事务中。
