20 年放置の MySQL Bug #11472 が WL#17024 で修正 — Cascade trigger 不発を MySQL 8.4 ユーザはどう備えるか

結論 — 20 年放置の MySQL Bug #11472 が WL#17024 で修正

MySQL の有名な長寿バグ #11472「Foreign Key の CASCADE で参照側 trigger が発火しない」が、Worklog #17024 で fix された旨が 2025 年 3 月の開発者コメントで announce されました。2026 年 5 月 27 日に Reddit r/programming で 1641 score まで再浮上したので、この fix を改めて読み直しました。

本サイト AetherEchoes は MySQL 8.4 LTS を本番採用しており（CLAUDE.md にも明記）、9.x に上げる前にこの挙動変更の前提を把握しておく必要があります。本稿は #11472 が「具体的に何を 20 年間壊していたか」と、WL#17024 の opt-in 設計、そして 8.4 で書いている私が今やっておくべき備えを順に書きます。リリースノートだけを読むと「直りました、よかったですね」で終わってしまう話を、自分のスキーマに置き直して整理した記録です。

バグの中身を最小 test case で見る — trigger が静かにスキップされる

#11472 を最短で理解するには、Omer Barnir が 2005 年 6 月 21 日の初回 bug report に添えた test case を読むのが早いです。テーブル t1 と t2 があり、t2 は t1 を外部キーで参照しています。t2 側に AFTER UPDATE trigger を置いて counter を回し、t1 の行を 1 件 DELETE する、というだけの最小再現コードです。

FK 定義が ON DELETE SET NULL なら、t2 の f_id 列は NULL に書き換わるはずで、AFTER UPDATE trigger は当然 1 回以上発火する、というのが SQL の常識的な期待でした。実際の MySQL（5.0.8 から 8.0 まで）はそうなりません。cascade で書き換えられた行に対して trigger は呼ばれず、counter は 0 のままです。t2 を直接 UPDATE すれば trigger は素直に動きます。同じ列に対する同じ書き換えでも、由来が cascade か直接更新かで挙動が分岐していました。

監査ログを trigger で書いていた人は、cascade 経由の変更が監査の網から漏れていた、ということです。私が初めてこの挙動を踏んだ時のメモには「データは消えているのに監査テーブルが沈黙している」と書いてあり、半日分の時間が溶けました。

20 年で何が変わって何が変わらなかったか — 報告から fix まで

#11472 のタイムラインを並べると、長寿バグの「待たされ方」が分かりやすいです。

• 2005-06-21: Omer Barnir が bugs.mysql.com に #11472 を報告（affected version 5.0.8）
• 2005〜2024: 影響範囲が 5.5 / 5.6 / 5.7 / 8.0 へ持ち越し（status は長く Verified のまま）
• 2025-03-17: developer Prabakaran Thirumalai が「Fixed as part of WL#17024」とコメント
• 2026-05-27: Reddit r/programming でこの thread が 1641 score まで上がり再浮上

報告から fix announcement まで 19 年と 9 ヶ月です。中学生だった私が今の年齢になった時間、と書くと急に他人事ではなくなります。同じ Reddit thread で「2005 年のバグレポートをスクロールしたら issue が自分より年上だった」というコメントが付いていて、画面の前で笑ってしまいました。バグレポートの方が私より年上、という体験は珍しい部類です。

長寿だった理由は技術的に直しにくかったから、ではなく 「直すと壊れるアプリケーションがある」 ことが主因と読んでいます。trigger が動かないことを前提に書かれた auditing / 二次集計 / soft delete のロジックが、20 年分の MySQL 本番に大量に存在します。後述の opt-in 設計はこの累積を踏まえた判断です。

WL#17024 の修正方針 — enable_cascade_triggers を opt-in にした理由

WL#17024（Activate triggers on referencing tables during foreign key CASCADE）が今回の fix で、対象は MySQL 9.x 系です。設計の肝は 3 点に要約できます。

1. session 変数 enable_cascade_triggers で opt-in。default は FALSE。明示的に TRUE にしたセッションでだけ cascade 時の trigger が発火します。
2. 対象は SQL-layer FK のみ。innodb_native_foreign_keys = ON の経路（InnoDB ネイティブ FK）ではこの変数の効果はゼロです。
3. BEFORE / AFTER trigger の発火順序を明示。BEFORE は親→子（top-down）、AFTER は子→親（bottom-up）。多段 cascade（最大 15 段、1 chain あたり最大 30 テーブル）でもこの順序を守ります。

opt-in を選んだのは互換性のためです。default を TRUE にすれば、20 年沈黙していた trigger が一斉に喋り出す本番が世界中で発生します。これは「過去の audit 実装に責任を持っている全員にロールバックの義務を負わせる」変更で、現実的ではありません。enable_cascade_triggers は将来 deprecation の対象として明記されており、いずれ TRUE が default になる前提のフラグです。「今のうちに opt-in にして自分のコードがどう挙動を変えるか観測しておけ」というメッセージと読みました。

私の MySQL 8.4 プロジェクトにどう影響するか — innodb_native_foreign_keys の話

本サイト AetherEchoes は MySQL 8.4 LTS を Docker で動かしています。8.4 系に WL#17024 はバックポートされず、target は 9.x です。そのため「明日から動作が変わる」ことは無いのですが、9.x への upgrade ロードマップを引く時の前提が 1 つ増えました。

加えて、本サイトの schema は Ridgepole で管理しており、FK は InnoDB ネイティブで張っています。innodb_native_foreign_keys が ON の経路では enable_cascade_triggers は no-op なので、9.x 化後も「とりあえず変数を ON にすれば trigger が動く」わけではありません。SQL-layer FK 経路に切り替えるか、cascade 由来の変更を「自分で UPDATE する」二度書きに整えるか、いずれにせよ移行設計が要ります。

実害が出るのは、monitoring / audit / 派生集計を trigger で組んでいて、かつ FK CASCADE を多用しているケースです。私のプロジェクトは幸いそのどちらでもないので、影響は「9.x upgrade 前のチェックリストに 1 行追加」で済みます。

9.x まで待てない人へ — 監査を trigger に頼らない 2 つの備え

8.4 で書いている人が「9.x まで cascade trigger 不発を抱える」ことは確定です。今からできる防衛策は 2 つあり、application 層で監査を書くか、CASCADE 自体を使わないか、どちらかを選ぶ話になります。

まず application 層案は、具体的には Rails の ActiveRecord callback、Sidekiq job 内の明示的な audit row 作成、で実装します。本サイトでは Rails 6.1 → 8.1 のメジャー移行で踏んだ 7 つの罠 で触れたように、PostRevision 系のモデルでこれを徹底しています。trigger に頼っていない分、cascade だろうが直接更新だろうが等価に audit が残ります。MySQL を入れ替える未来があっても application 層のコードは持って行ける、という移植性も利点です。

もう一方の CASCADE 撤廃案は、FK を ON DELETE RESTRICT（または NO ACTION）にしておき、削除を service クラスで 2 段階に分ける、というやり方です。1 段階目で子レコードを destroy、2 段階目で親を destroy。コード量は増えますが trigger 経路を踏まないので #11472 とは無関係になります。「CASCADE を書かない」ことを規約にしている現場をいくつか知っていますが、その理由の半分くらいはこの #11472 の挙動だろうと思っています。

20 年放置と聞くと身構えてしまいますが、自分の手元で実害が出ているかどうかは別問題です。MySQL 9.x 以降に upgrade する時の checklist に 1 行足しておく、というのが今のところ私のアクションです。皆さんの schema はどうでしょうか。