MySQL触发器无法捕获ON UPDATE/DELETE CASCADE引发的子表变更，因InnoDB在引擎层直接改写数据，绕过SQL层触发器调度。
外键级联变更根本不会进入触发器执行路径
MySQL 触发器完全无法捕获由 ON UPDATE CASCADE 或 ON DELETE CASCADE 引发的子表变更——这不是 bug，也不是配置遗漏，而是 InnoDB 引擎层的硬性设计。当主表更新或删除触发级联时，InnoDB 直接在存储引擎内部完成子表行的修改，全程绕过 SQL 解析器、查询优化器和触发器调度器。
这意味着：AFTER UPDATE 触发器即使定义在子表上，也不会被级联更新激活；OLD 和 NEW 在这类变更中根本不存在，因为没有“语句上下文”参与。
- 执行
UPDATE users SET id = 1001 WHERE id = 1000，若orders.user_id外键设了ON UPDATE CASCADE，则orders表的对应行会被引擎直接改写，不走任何触发器逻辑 -
SHOW WARNINGS、慢日志、甚至SELECT @@innodb_monitor_enable都不会记录这次“触发”，因为它压根没被调度 - 子表上同时存在外键约束和触发器，二者完全解耦：一个在引擎层干活，一个在 SQL 层待命
为什么不能靠子表触发器“补漏”
有人试图在子表加 AFTER UPDATE 触发器来捕获级联结果，但这条路从机制上就走不通。更危险的是，这种设计容易引发逻辑重复或数据错乱：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 主表变更 → 引擎自动更新子表（无触发）→ 应用层又手动 UPDATE 同一行 → 触发器被激活 → 二次处理（比如重复记日志、双倍扣减库存）
- 若触发器里还做了跨表写入（如更新统计表），而该统计逻辑本应只响应显式业务操作，就会污染监控口径
- 级联本身是原子事务的一部分，但触发器执行属于同一事务上下文，一旦触发器出错（如插入日志表失败），整个级联操作会回滚——这反而破坏了外键本意保障的数据完整性
真正能监控级联变更的三种可行方式
想感知外键级联带来的实际数据变动，必须跳出“在子表加触发器”的思维定式。可用方案只有以下三种，且各自适用场景明确：
-
监听主表变更 + 主动查子表：在主表的
AFTER UPDATE触发器里，用SELECT ... INTO查出被级联影响的子表记录，再做通知或审计。注意这只是“事后确认”，不能替代级联动作本身 -
解析 binlog（ROW 格式）：启用
binlog_format = ROW，用mysqlbinlog或 Debezium 捕获真实写入事件。所有级联产生的子表变更都会出现在 binlog 中，但这是外部系统行为，与触发器无关 -
放弃外键级联，改用应用层事务：先
UPDATE users，再同一事务内显式UPDATE orders。此时所有 DML 都可控，可自由加触发器、日志、校验逻辑——代价是开发成本上升，且需严格保证事务边界
最容易被忽略的性能与一致性陷阱
很多人在测试库验证时发现“子表触发器好像能跑通”，往往是因为测试数据量小、并发低，掩盖了底层机制差异。真正上线后容易暴雷的点是：
- 级联操作本身会锁子表相关行（甚至全表扫描验证），若再叠加触发器里的额外查询或写入，延迟会明显放大
- 使用
ON UPDATE CASCADE时，如果子表外键列没建索引，ALTER TABLE加约束会失败，而运行时级联更新性能也会急剧下降 - 跨库、MyISAM 表、或需要条件跳过的级联逻辑（比如“仅当订单状态为 draft 时才级联删除”），外键根本不可用，这时触发器也不是银弹，得回归应用层控制
