mysql触发器无法捕获外键级联删除，因on delete cascade由innodb引擎层直接执行物理清理，不构造delete语句、不经过sql解析器，故完全跳过触发器调度链；唯一可控响应点是父表before delete触发器，仅能预判不能监控实际结果。
外键级联删除根本不走触发器执行路径
MySQL 触发器无法捕获外键级联删除，不是配置漏了、权限不够，也不是触发器写错了——它压根就不会被调用。因为 ON DELETE CASCADE 是 InnoDB 引擎层直接完成的物理清理，不经过 SQL 解析器，也不构造任何 DELETE FROM 语句，自然跳过了整个触发器调度链。
常见错误现象包括：
- 你在
order_items表上明确定义了BEFORE DELETE触发器，用于记录日志或校验依赖 - 但当
orders表中某行被删、order_items中关联行随之消失时，日志表空空如也 -
SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'order_items'能查到触发器，但它就是不运行
父表 AFTER DELETE 触发器不能“补救”级联行为
有人试图在父表（如 orders）上建 AFTER DELETE 触发器，手动执行 DELETE FROM order_items WHERE order_id = OLD.id，以为这样就能“激活”子表触发器。这条路走不通，原因很实在：
- 这么做等于自己实现级联逻辑，必须先禁用原有外键，否则会报
ERROR 1452（违反外键约束） -
AFTER DELETE触发器不参与事务回滚：如果后续语句失败，父表行恢复，但子表数据已永久丢失 - 你失去的是外键最核心的价值——参照完整性保护，应用误操作可能留下孤儿数据
唯一可控的响应点是父表的 BEFORE DELETE
如果你必须对“级联即将发生”做反应（比如记审计日志、发通知、预校验），唯一稳定入口是父表自身的 BEFORE DELETE 触发器。但它只能预判，不能监控实际结果：
- 可在
BEFORE DELETE ON orders中用SELECT COUNT(*) INTO @cnt FROM order_items WHERE order_id = OLD.id检查子项是否存在 - 再决定是否写入审计日志、调用存储过程，或抛出异常中断删除
- 注意：不能在触发器里开启事务或调用含事务的存储过程，MySQL 会直接报
ERROR 1305
想真正捕获级联变更，得换机制
依赖触发器捕获外键级联结果，这条路从引擎层面就堵死了。可行替代方案只有：
- 放弃外键级联，改用应用层事务：同一事务中先
DELETE FROM order_items，再DELETE FROM orders，全程可控 - 启用
binlog_format = ROW，用mysqlbinlog或 Debezium 解析真实写入流（这是外部系统行为，与触发器无关） - 在父表
AFTER DELETE中主动查子表状态做补偿（仅适合事后审计或通知，不能替代级联语义）
最容易被忽略的一点：很多人以为给子表加触发器 + 外键级联就能“双重保障”，实际上二者互不感知，反而可能因逻辑重复导致数据错乱或性能浪费。
