在数据库设计里，外键的ON DELETE CASCADE是个省心的功能，设定好之后，删除父表记录，子表关联数据自动清理，看似完美。但如果你在子表上精心设置了DELETE触发器，指望它能对这次“自动清理”做出响应，比如记录个审计日志，那你很可能会失望。你会发现，数据确实没了，但触发器却静悄悄的，仿佛什么都没发生过。
ON DELETE CASCADE 会跳过被引用表的 DELETE 触发器
这并非程序出了错，而是MySQL有意为之的设计。官方文档说得很清楚：当父表删除操作通过外键约束触发级联删除时，子表上定义的DELETE触发器将完全不会执行。原因在于，级联删除这个动作是由存储引擎（比如InnoDB）在底层直接完成的，它绕过了处理触发器的SQL层。两套机制，各走各的路。
实际开发中，这个特性常让人踩坑。举个例子：你在order_items（订单明细）表上写了个BEFORE DELETE触发器，本意是每次删除明细时，都在另一张日志表里留个记录。但当你在orders（订单）表删除一条主订单时，虽然关联的所有明细行都被级联删除了，回头一查日志表，却空空如也。你用SELECT * FROM information_schema.TRIGGERS去查，触发器明明在那里，但它就是“不响”。
为什么不能靠“在父表建触发器”来补救
既然子表触发器不灵，那能不能在父表上动脑筋？比如，在orders表的AFTER DELETE触发器里，手动执行一条DELETE语句去清理子表数据，这样不就能触发子表的触发器了吗？
这个想法听起来合理，但实践起来问题不少。首先，这么做等于你自己用代码实现了级联逻辑，那么原先外键上的ON DELETE CASCADE就必须禁用或删除，否则会引发外键约束冲突错误。其次，一个更隐蔽的风险在于：AFTER触发器内部如果发生错误，它不会导致整个事务回滚。想象一下，父表记录删除后，触发器里的手动删除子表语句成功了，但后续某个操作失败了，这时父表的删除可能被回滚，但子表的数据却已经永久消失，造成数据不一致。
真正能响应级联动作的唯一位置：父表的 BEFORE/AFTER DELETE
那么，如果业务上必须对“发生了级联删除”这个事件做出反应（例如更新汇总统计、发送通知），正确的入口在哪里？答案是，只能在父表自己的触发器里做文章，而且只能是基于预判或事后记录。
你可以在orders表的BEFORE DELETE触发器中，先查询一下将要被删除的订单有多少关联明细，然后根据这个结果决定是否写入日志或调用其他逻辑。也可以在AFTER DELETE触发器中，安全地记录一条“某父记录已被删除”的审计日志。但必须清醒认识到，这记录的只是父表操作本身，并不能百分之百代表子表数据一定通过本次级联被删除了（万一外键临时被禁用了呢？）。
另外要特别注意，MySQL不允许在触发器内部显式开启事务或调用某些涉及事务控制的存储过程，设计逻辑时要避开这些陷阱。
调试时最容易忽略的静默失效点
“级联删除后触发器没反应”这个问题，在调试时常常让人误入歧途。开发者第一反应可能是触发器写错了，但更可能的情况是，触发器根本就没被调用。
有几个检查点容易被忽略：首先，执行完删除后看看SHOW WARNINGS，如果什么都没输出，那基本说明触发器没被执行，而不是执行中间出错。其次，反复确认外键约束的定义，确保上面写的是ON DELETE CASCADE，而不是RESTRICT或别的。再者，检查一下触发器是否被意外禁用（虽然低版本MySQL的DISABLE语法可能实际无效）。最后，别忘了查询SELECT @@foreign_key_checks，确保外键检查是开启状态，如果被临时关闭，级联行为会消失，且不会报错，只会留下一堆孤儿数据。
说到底，外键级联和触发器在MySQL中是两套独立的机制。一个在存储引擎层疾驰，一个在SQL层待命。它们之间没有握手，也没有通知。想让它们协同工作，往往意味着你要放弃其中一方的“全自动”，把控制权收回，在应用层或更明确的事务逻辑中，自己来编排这一切。
