MySQL触发器无法响应ON UPDATE/DELETE CASCADE操作，因级联由InnoDB引擎层直接执行，不经过SQL解析器和触发器调度队列；唯一可监听的入口是父表BEFORE触发器，用于预判而非捕获实际变更。
触发器根本收不到级联操作的通知
MySQL触发器不会响应任何由ON UPDATE CASCADE或ON DELETE CASCADE引发的变更。这不是bug，是InnoDB引擎层的设计：级联动作在存储引擎内部完成，不经过SQL解析器，也就压根不进触发器调度队列。
典型现象包括：
- 你在
order_items表上建了AFTER DELETE触发器，但父表orders删一行后，该触发器完全不执行 -
SHOW TRIGGERS能查到定义，SELECT日志表却为空，错误日志里也无记录 - 误以为“主表触发器 + 子表外键级联”能双重保障，结果二者互不感知，反而可能因逻辑重复导致数据错乱
别在触发器里手动模拟级联逻辑
有人想绕过这个限制，在父表AFTER DELETE触发器里手动写DELETE FROM order_items WHERE order_id = OLD.id，这条路风险极高：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须先
DROP FOREIGN KEY，否则会报ERROR 1452（违反外键约束） -
AFTER触发器不参与事务回滚：如果后续语句失败，父表行恢复，但子表数据已永久丢失 - 你主动放弃外键最核心的价值——自动化的参照完整性保护，留下孤儿数据隐患
唯一可控入口是父表的 BEFORE 触发器
如果你必须对“级联即将发生”做反应（比如审计、通知、预校验），唯一稳定入口是父表自身的BEFORE DELETE或BEFORE UPDATE触发器。但它只能预判，不能监控实际结果：
- 可在
BEFORE DELETE ON orders中用SELECT COUNT(*) INTO @cnt FROM order_items WHERE order_id = OLD.id检查子项数量 - 再决定是否写入审计日志、调用存储过程，或用
SIGNAL SQLSTATE '45000'抛出异常中断删除 - 禁止在触发器里开启事务、调用含事务的存储过程，MySQL会直接报
ERROR 1305
真正需要捕获级联变更时，得换机制
依赖触发器捕获外键级联结果，这条路从引擎层面就堵死了。可行替代方案只有：
- 放弃外键级联，改用应用层事务：同一事务中先
UPDATE/DELETE子表，再操作父表，全程可控 - 启用
binlog_format = ROW，用mysqlbinlog或Debezium解析真实写入流（注意：这是外部系统行为，与触发器无关） - 在父表
AFTER触发器中主动查子表状态做补偿（例如：用户状态变archived后，查SELECT COUNT(*) FROM orders WHERE user_id = OLD.id并记录日志）——但这仅适合事后审计或通知，无法替代级联本身
最易被忽略的一点：很多人把外键级联和触发器混着用，以为多一层更安全，实际上二者运行在完全不同的执行路径上，既不协同也不通信，反而增加理解成本和维护风险。
