mysql触发器无法捕获外键级联更新，因innodb引擎层直接执行级联操作，绕过sql解析器与触发器调度流程，不生成old/new上下文；仅显式dml语句可触发，mysql 9.6.0是唯一例外但尚未普及。
MySQL 触发器无法让级联更新触发下一级触发器，根本原因不是写法或配置问题，而是引擎层不把外键级联当作“可触发的 SQL 事件”——它压根不进触发器调度流程。
外键级联变更绕过整个 SQL 层
当定义了 ON UPDATE CASCADE 的外键后，InnoDB 直接在存储引擎内部完成子表行的修改，不经过 SQL 解析器、优化器，也不生成 OLD/NEW 伪记录。这意味着：
-
AFTER UPDATE触发器即使建在子表上，也完全收不到通知 -
SHOW WARNINGS查不到线索，错误日志里也无记录——不是失败，是“没启动” - 哪怕你在子表同时定义了外键和触发器，二者互不感知：外键干活，触发器晾着
显式 DML 才是唯一能激活触发器的操作
只有客户端或应用层发起的原始 INSERT/UPDATE/DELETE 语句才会触发对应表的触发器。外键级联属于隐式引擎行为，与 SQL 层面的 DML 完全解耦。例如：
-
UPDATE users SET id = 100 WHERE id = 123→ 若orders.user_id外键设了CASCADE，则orders表更新不走任何触发器 -
DELETE FROM users WHERE id = 123引发的子表删除，也不会激活order_items上的BEFORE DELETE或AFTER DELETE
MySQL 9.6.0 是唯一例外，但仅限新版本
截至 2026 年 8 月，MySQL 9.6.0（Linux 专用）将外键级联操作从 InnoDB 引擎层上移至 SQL 层，使得所有变更均可被触发器捕获，并完整记录到 binlog。但该版本尚未在生产环境大规模落地，且不兼容旧版 MySQL 协议与工具链。
如果你当前用的是 MySQL 5.7/8.0/8.4，这条路就是堵死的——别在子表触发器里等级联通知，它永远不会来。
真正容易被忽略的是“你以为在触发，其实什么都没发生”
很多排查者反复检查触发器语法、权限、状态，却没意识到：外键级联本身就不走触发器路径。最省时间的做法是立刻放弃“靠触发器监听级联”的思路，转而用应用层事务控制（先改主表，再同一事务里显式更新子表），或启用 binlog_format = ROW + 解析 binlog 捕获真实写入流。后者虽是外部机制，但它是目前最稳定、可验证、跨版本可用的方案。
