MySQL触发器不响应外键级联操作，因InnoDB在引擎层直接执行CASCADE，绕过SQL解析与触发器调度；仅显式DML语句触发触发器，级联变更无OLD/NEW上下文，监控须改用应用事务、binlog解析或主表触发器补偿。
MySQL触发器根本不会响应外键级联操作产生的变更——这不是配置问题，也不是权限问题，是InnoDB引擎层的硬性设计决定。
外键级联动作不经过触发器执行路径
当定义了 ON UPDATE CASCADE 或 ON DELETE CASCADE 的外键约束后，级联更新或删除由InnoDB存储引擎在底层直接完成，全程绕过SQL解析器和触发器调度器。这意味着：
- 即使你在子表（如
order_items）上定义了AFTER UPDATE触发器，它也不会被外键级联引发的行变更触发 -
OLD和NEW在这类变更中完全不可见，因为根本没有“语句上下文”参与 - SHOW WARNINGS、错误日志、甚至
SELECT @@innodb_monitor_enable都不会记录这类变更的触发器调用痕迹
BEFORE/AFTER 触发器只响应显式DML语句
触发器仅对客户端或应用层发起的原始 INSERT / UPDATE / DELETE 语句生效。外键级联属于“隐式引擎行为”，不在这个范畴内：
-
UPDATE users SET status = 'archived' WHERE id = 123→ 若users.id是orders.user_id的外键且设了CASCADE，则orders表的更新不走任何触发器 - 同理，
DELETE FROM users WHERE id = 123引发的子表删除，也不会激活order_items上的BEFORE DELETE或AFTER DELETE触发器 - 哪怕你在子表上同时定义了外键 + 触发器，两者完全解耦：外键干活，触发器晾着
想监控级联变更？必须换机制
依赖触发器捕获外键级联结果，这条路从引擎层面就堵死了。可行替代方案只有：
- 放弃外键级联，改用应用层事务：先
UPDATE users，再同一事务里UPDATE orders，此时可自由加触发器或日志逻辑 - 启用 binlog + 解析 ROW 格式事件：用
mysqlbinlog或 Debezium 捕获真实写入流，但这是外部系统行为，与触发器无关 - 用
AFTER UPDATE触发器监听主表变更，再主动查子表状态做补偿（注意：这不能替代级联，只是事后审计或通知）
最易被忽略的一点：很多人以为给子表加触发器 + 外键级联就能“双重保障”，实际上二者互不感知，反而可能因逻辑重复导致数据错乱或性能浪费。
