ついに決着！MySQLの悪名高い20年越しのバグ「#11472」がついに修正されました

:) https://xkcd.com/1172/

ポーランドの「Yanosik」っていうGPSアプリがあるんだけど、この冬にCPUを使いすぎるバグがあって、使ってるとスマホがめっちゃ熱くなってたんだ。

俺の車はフロントガラスの霜取りをする時の暖房がすごく効きにくくてさ。だから、霜取りを早めるための追加のヒーター代わりとしてこのアプリを使ってたんだよ。

バグが修正された時は本当にがっかりしたよ。霜取りが大変になった／時間がかかるようになったからね（笑）。

#追記
修正後にスマホ用のCPUストレステストやベンチマークソフトなんかはダウンロードしてないよ。スパイウェアとかアドウェアとか混じってたら怖いしね：P

その5ワットが本当に役に立ったと確信してるよ

うちの車載カメラは、プラグ抜かないと気温が-5℃以上の時に綺麗に円形に霜取りしちゃうよ。スマホも同じくらい良いアシストをしてくれるはず :P

それが何の違いも生まなかったと断言できるよ

ちょうど昨日このことについて考えてたところだよ。

でもマジな話、これだけ長い間あったバグなら世の中に無数の回避策が存在してるはずだし、この修正のせいでそのどれかが壊れても不思議じゃないよね。

一番よくある回避策は「MySQLを使わないこと」だな。

ああそうか、「Stack Exchange」流のやり方を忘れてたよ……技術スタックを別のものに変えちゃうっていうね。

いっそ木こりにでもなれば？

俺は木こりだけど元気だぜ

そもそも使い始めてなかったら「変更」にはならないしね。MySQLは昔から欠陥だらけで、標準から外れてるよ。

Oracleのコンサルタント発見。

OracleがMySQLを所有してるのに、なぜOracleが「不十分」なんて言うわけ？…まあ、当然彼らは真の救世主であるpostgresqlを推してたんだろうけど。

Oracle DBのライセンス料を払えるのに、わざわざ彼らのFOSSソフトウェアを使う理由って何？

参照整合性の要件が理由の一つかもしれないね。

「あらら、またオープンソースの『顧客』を有料版に取られちゃったよ！一体どうすりゃいいんだよ？？？？」

在庫を確認して。

そうだな、たかが一番よく使われてるFOSSデータベース技術だし、誰もMySQLなんて使ってないよな。

みんなでMongoDBを使おうぜ、Webスケールも扱えるし2018年にはACID準拠にもなったんだから。

MongoDB is web scale: https://youtu.be/b2F-DItXtZs

いや、今回の件は「『罠』が1000個あるデータベースを避ける方法」みたいな話だよ。20年間で遭遇してきた数十個の罠に比べれば、こんなの屁でもないし、彼らの解決策はクライアント側でオンオフ切り替えられるようにすることだったしな。

冗談抜きで、MySQLユーザーってDB固有の機能を必要としないことが多いから、移行が一番楽なんだよね

20年間ずっとインストールされてるけど一度も動いてないトリガーとか絶対あるでしょ。もしそれが予期せず動き出したり、20年前のバグを抱えてたりしたら、原因追及する人は災難だろうな。

予期せぬトラブルに巻き込まれた人は、適切な変更管理プロセスに従わず、本番環境へのデプロイ前に新しいアップデートをテストしなかった自分のせいだよ。開発環境で変な挙動が起きたとしても、原因を突き止める必要があるなら、それは「悪い一日」じゃなくて「興味深い一日」ってことさ。

そうだよ、全ての「まともな企業」は最初から厳格なベストプラクティスを守って、常に「全ての技術的負債を完済」してるからね！レガシーなデータベースやゴミコードを抱えてる会社なんて？そんなこと想像できるわけないだろ！

トリガーの変更によって引き起こされる問題をすべて解決するまでは、プロダクション環境にアップデートを適用しなきゃいいだけ。ちゃんとした変更管理プロセスさえあれば、別に大した問題じゃないよ。もし「レガシーな問題やゴミコード」が山積みで、わざわざ修正する価値もないなら、MySQL Serverをアップデートしなければいい。パッチノートも読まず、テストもしないままアップデートを強要してくる人なんて誰もいないでしょ。

これで不意打ちを食らった奴は自業自得

あるいは、開発環境やテスト環境には入れずに直接プロダクション環境にトリガーを仕込んだ前任者のせいかもね。仕事で何度もそういう現場に遭遇したよ :)

幸い、俺はMySQLを使ってないけど。

誰もこれの影響なんて受けないよ……。

……金曜日まではね。

本番環境でテストするのに最高の日だね！

まあ公平に見て、そのほとんどは未だにMySQL 5を使ってて、一生アップデートしないだろうけどね。

そのバグに関するコメントスレッド全体で、回避策はないって言ってる人が何人もいたぞ。何人かはそのバグを避けるためにPostgresかOracleに移行したって言ってたな。

未定義の挙動や壊れた挙動に依存しちゃダメだ。

真面目な話、これかなり多くのデータベースで不具合が出るよ。

9.7（先月リリース）だと、enable_cascade_triggers=onに設定しないとデフォルトで古いメソッドになっちゃうね。そのうち将来のバージョンで廃止されるだろうけど、まあ10年以上先の話でしょ。

https://lawsofsoftwareengineering.com/laws/hyrums-law/

ハイラムの法則（Hyrum’s Law）だね。

例のあれ、関連するxkcdがあるよね

これは受け入れられないよ。そろそろフォーク（派生版を作る）する時期なんじゃないか？

コメント欄最高だな！

で、良かったのか？

たぶん古すぎてほとんどのユーザーにはロックされてるんじゃない？

コメント欄全体が最高すぎる：

[2005年6月30日 19:04] 5.1で修正予定

[2007年2月21日 12:56] MySQL独自のFOREIGN KEY実装でいずれ修正される予定だが、まだ時間がかかる

[2007年6月4日 20:00] バージョン5.1.11現在、依然としてこの問題は存在

[2009年7月2日 15:42] このバグは5.1では修正されない

[2011年3月13日 14:37] 5年経ったが、まだ修正されていない

[2013年5月8日 12:29] もうすぐ8年だ…何か進展は？

[2013年5月8日 13:25] Oracleの連中はトリガーが発動してないから、このメッセージにも気づいてないんだろうな ;)

[2013年5月8日 13:52] この問題を直すには大幅な改修が必要。単なるバグ修正では済まない

[2015年6月21日 8:38] 記念日おめでとう！ついに10年だ…

[2015年6月24日 21:42] この不具合も秋には中学生か

[2018年6月21日 18:02] 13歳の誕生日おめでとう、11472番！成長が早いね :')

[2019年11月11日 9:12] バグ報告を立てた人が今どうしてるか知りたいな。まだ生きてる？まだMySQL使ってるのか？

[2019年11月12日 14:29] 気にかけてくれてありがとう。元気だし、まだMySQL使ってるよ

[2020年6月11日 21:36] このバグ、俺より年上なんだけど

[2020年7月15日 12:28] みんな、彼女がこのバグが直ったら結婚してくれるって言ってるんだ。何か進展はないか？追伸：2017年から待ってるんだけど、彼女がGaryと付き合いそうなんだ。追伸2：Gary、お前は最低だな！

[2021年1月18日 0:49] 俺たちの愛すべきバグがコロナ禍を生き延びたか確認しに来た。元気そうで何よりだ。

[2026年3月17日 10:14] WL#17024の一部として修正済み

[2021年1月18日 0:49] 俺たちの愛すべきバグがコロナ禍を生き延びたか確認しに来た。元気そうで何よりだ。

腹筋崩壊した

このバグは俺より年上

チャットに14歳がいるってこと？

まあ、もう20年も前の話だからね。

大学で無給のインターン探してる身で、どうやってMySQLの10年以上の経験を積めって言うんだよ？

この件に触れたXKCDのコミックが出るのを待つしかないな……。

まあ、彼がゲイリーから彼女を取り戻せることを祈るよ。

間違いなく、不正な日付を許可するようなコンフィグファイルの設定が必要になるパターンのやつだな。

😆

誰もあえてこれに依存してるとは思わないけど、今まで発火しなかったトリガーが動くようになるのは、実際の運用環境で何かしら壊す原因になりそう。

半分冗談で半分本気なんだけどさ。

前の挙動は「間違って」はいたけど、20年も続いてきたものだろ。新しい挙動は「正しい」けど全く別物。これから何が起きるか見ものだね。

そんなに多くはないかな。こういうバグがあるせいで、真面目に仕事をしてる人なら、なぜシンプルに保つ必要があるのか、あるいはさっさとPostgresやMariaDBに移行すべきなのか、すぐに気づくからね。

添付されてる作業ログを読みなよ。デフォルトでは無効になってるから、明示的にオンにする必要があるぞ。

多分それには依存してないだろうけど、期待はしてるから、結果的に挙動が二重に発生するような回避策が残っちゃうんだろうね。

うーん、そのテーブルからエントリーを削除できるのは外部キー制約だけにするために、トリガーを使うのがめちゃくちゃ賢いやり方だと思ってた場所が少なくとも一箇所あるんだよね……

いつかね。今日じゃないけど、いつかきっと。

Half Life 3が出てくれたらそれで満足だよ。そういえば、もうHalf Lifeより後に生まれて成人した人たちがいるんだよな……。

そこがバグじゃないんだよ。バグってのは、カスケードによって外部キーが更新された時、そのテーブルのUPDATEトリガーが実行されてなかったってこと。

わかるよ。ターゲットが削除されたときに外部キーフィールドが変更されて、トリガーが起動するなんて期待しないよね。

テーブルは更新されなかったの？

まあそんな感じかな。リファレンスが有効なままになるように更新されたんだ（NULLが許可されてて、孤立レコードになったことを示すようになっている）。でも、UPDATEコマンドで更新されたわけじゃないんだよ。

だから何？データは更新されたんだから、テーブルの更新トリガーは発火するはずでしょ。これって実質的にどのDBMSでも同じじゃないの？

それはデータベースが自身の整合性を保つための更新であって、ユーザーやアプリケーションのための更新じゃないんだよ。DBの内部構造に依存しなきゃいけないような状況まで追い込まれた時点で、君が何か間違ったことをしたのかもね。

というか、監査に関わるようなクリティカルなコードパスに対して結合テストをしてないなら、それは自業自得じゃないかな。

最近は仕方なく使うって時くらいだわ。

初めてこれに出会ったのは2001年くらいかな。当時MSSQL使ってて、サブでPostgresを試してた時。インストールしてくれたsysadminが速さに驚いてたけど、小規模データにしか向かないって言ってた。確実に当初の想定を超えて成長したよな。

こういう考え方を何も分からずにソリューションに取り込んでるソフトウェアエンジニアを腐るほど見てきたわ。

ある視点から見れば、データモデリング（ORMを使う場合）はすべてコードで行うべきだよね。それが信頼の源泉だから。外部キーを使うとコストがかかるからって、Webスケールを言い訳にして避けたがる開発者もいるけどね（皮肉）。

本当のこと言うと普通は2つテーブルが必要だけど、正しいパラダイムを使えば1つで済むよ（table_name, column_name, row_num, value_type, value）。最高にパフォーマンスが出るから

DynamoDBを使ったことがあるんだね

以前働いていた会社で、「主キー（primary keys）を実装するのはコストがかかりすぎる」なんて言い張る奴を雇ったことがあるよ。3週間でクビにしたけどね。

面接で触れられなかったのは残念だな。まあ、仕方ないか。

決定的な瞬間は何だったの？彼が何をやらかして「もうお前は終わりだ」ってことになったの？

俺がそのコメンテーターじゃないから断言はできないけど、もし俺の立場なら、トリガーが既存の制約を無視したり、必要のないフラグやフィールドをテーブルに追加し始めたりすることを懸念するかな。

なるほどね。てっきりもっとヤバい妄想狂みたいな話かと思ってたよ。例えば、プライマリキーを使わない新しいスキーマにデータを移行しようとするとか、そういう破滅的なレベルのやつ。

まあ、そりゃそうだよ。ORMが全部やってくれるなら、そんなクソみたいなこと気にする必要ないもんな？ 🤔

決定的なひとつがあったわけじゃなくて、過去50年のRDBMSの研究開発を理解しようとしない姿勢がずっと続いてただけだと思う。石に滴る水が最後には穴をあけるみたいに、ここが限界っていう一点があるわけじゃなくて、すべての滴が影響してたんだよ。

あー、だから外部キーが全くないPHPスタックにいくつも当たったのか。

君だけじゃないよ！

誰かこのページのアーカイブを持ってる？リレーショナルDBの主要な機能をサポートしない理由を読んでみたいんだよね。

何年もずっと探してたんだ。たまに同じページについて言及してる人を見かけることはあっても、肝心のページ自体はどこにも見当たらないんだよ。

思い返してるのは90年代後半から2000年代初頭の話だけどね。

https://www.reddit.com/r/programming/s/R60XqLPV9Q

https://www.reddit.com/r/programming/s/R60XqLPV9Q

その後、NoSQLのムーブメントが来て、それが売り文句になったおかげで、参照整合性がないことが急にイケてるやり方みたいになっちゃったんだよな。

ああ、まさにそれ。SQLを理解してないせいで起きたひどい出来事が山ほどあるよ。

SQLはオラクルのPL/SQLが何を望もうが、標準的な手続き型プログラミング言語じゃない。集合論を表現したものなんだ。それを理解すれば、もっと使いこなせるようになるはず。複雑すぎず単純すぎず、ただ自分が扱っているデータセットをそのまま網羅しようとしているだけ。専門用語としてじゃなくて、あるいは「扱うべきデータの集まり」を指す口語的な表現としてじゃなくて、数学的な集合として捉えるんだ。

これがわかれば、SQLは最高の相棒になるよ。

現実世界のアプリケーションは複数のデータストアにまたがってデータを保存してるから、厳密な参照整合性を保つのは不可能だよ。サブセットで外部キーが使えるのは便利だけど、結局のところ参照整合性のチェックはコードに頼らざるを得なくなるんだ。

NoSQLは素晴らしいよ……特定の条件下での問題に対してはね。でも相変わらず、みんな「バズってる＝どこでも使える」って勘違いしちゃうんだよな。

そしてNoSQLムーブメントがやってきた

SQLが登場する前は、すべてがNoSQLだったんだ。だからこそSQLが生まれたのさ。

とはいえ、SQLは厳密には「リレーショナル」ではないんだけど、それでも以前のものよりは遥かにマシだ。

悲しいことに、NoSQLのソリューションが理にかなっている場所はたくさんある一方で、データベースを理解していないからという理由でNoSQLを使っているクライアントにもたくさん遭遇してきたよ :(

（一番面白かったのは、あるクエリが15分かかってタイムアウトするからという理由でNoSQLを使おうとしていた会社かな。インデックスについて聞いたこともないリード開発者だったらしく、俺が手を加えたら1秒未満で終わるようになったよ）

SQLデータベースなのに、初期のNoSQLみたいな雰囲気出してるの面白いな

そうそう、MySQLのトップだったMonteが、外部キー、ビュー、サブセレクト、トリガー、ユニオン、トランザクションなんてのは開発者の90%には不要だって説いて回ってたんだよ。みんなそんなの必要としてないし、導入してもプログラミングが難しくなるだけで何のメリットもないってね。7年くらい前にデンバーのデータカンファレンスで聞いた話だと、ビッグデータなんてものは存在しないとか言ってたよ。どんなデータも、巨大なMySQLサーバー1台で処理できないものなんてないんだってさ。彼が言ってたことのほとんどは、ゴミみたいなMySQL製品の限界を正当化するためのデタラメだったよ。何千人ものプログラマーとプログラムをダメにした責任は、彼にあるね。

OracleはMySQLを所有していて、彼らは商用SQL製品であるDB2も持っている。Oracleには、MySQLをクソなままにしておく商業的なインセンティブがあるんだよ。その事実を知ってたら、なぜ未だに他のRDBMSを差し置いてMySQLを選ぶ人がいるのか、どうしても理解できないな。

まあ、今はそうなんだけどさ。でも、このクソみたいな状況は買収されるよりずっと前から続いてたからね

うーん、実は違うんだ。DB2はIBMのものだし、昔からずっとMVSの時代からAIX、そしてWindowsに至るまでそうだよ。

Oracleのデータベースソフトウェアの名前がOracleであって…

彼らがMySQLを買収した理由については君の言う通りだね。競合にならないようにするためさ。

昔のゴミ仕様はMyISAMエンジンのせいだからだよ。InnoDBはかなりモダンでまともだし。

うわっ、懐かしいタイムカプセルが出てきたな！これ、2000年当時の MySQL 3.23バージョンのマニュアル の一部だ。古いFTPサーバーを漁るのが面倒な人のために、該当箇所を抜粋しておくよ。

5.4.5.1 外部キー（FOREIGN KEY）を使わない理由

外部キーには問題が多すぎて、どこから手をつければいいのか分からないほどだ：

• 外部キー定義はデータベース内に保存しなければならず、実装するとファイルを移動・コピー・削除できるという「優れたアプローチ」を破壊してしまうため、生活が非常に複雑になる。
• INSERTやUPDATE文において速度への影響がひどい。そもそもほとんどの場合、レコードを正しいテーブルに正しい順序で挿入するため、外部キーチェックは無意味だ。
• 1つのテーブルを更新する際、サイドエフェクトがデータベース全体に連鎖する可能性があるため、より多くのテーブルをロックし続ける必要がある。レコードを削除するなら、1つのテーブルから削除して次に別のテーブルから削除する方がはるかに速い。
• テーブルをフル削除してから（新しいソースやバックアップから）全レコードをリストアすることができなくなる。
• 外部キーがあると、非常に特定の順序で行わない限り、テーブルのダンプやリストアができない。
• 定義自体は有効で使えるものであっても、循環定義が簡単にできてしまい、単一のcreate文でテーブルを再作成することが不可能になる場合がある。

外部キーの唯一の利点は、ODBCやその他のクライアントプログラムがテーブル間の接続関係を把握し、接続図を表示したりアプリケーション構築を支援したりできることくらいだ。

MySQLは近いうちに外部キー定義を保存するようになる予定だ。そうすればクライアントは元の接続関係を問い合わせられるようになる。現在の「.frm」ファイル形式には、それを格納する場所がないからね。

これだ！これこそがそのモンスターだ。何年も探し回ってたんだよ。本当に、とんでもなく的外れなゴミの山だな。

正気の沙汰じゃないな。時代遅れもいいとこだよ

あのページ、覚えてるよ。本当に……恐ろしい内容だった。以前は日付型も提供してたけど、ドキュメントには「日付のバリデーションはSQLサーバーの仕事じゃない」なんて書いてあったしね。あと、MySQLが不正な日付を「NULLでもありNOT NULLでもある」と判断してしまう古いバグもあったな。

記事の本文と図で、親テーブルと子テーブルの更新順序が食い違ってるのが面白いね（図の読み方が合ってればだけど）。プレゼンのスライドっぽいし、図を作った人と意思疎通ができてなかったのか、それとも実装が変わっちゃったのか気になるところだ

正直、グラフを細かく見てなくて、テキストだけ読んでたから（自分の中では）筋が通ってるように思えたんだよね。もしかして作者が汎用的な図を使い回したとか？いずれにせよ、もし彼がそれをやり遂げた張本人なら、素晴らしい実績として履歴書に書くね😬

まあでも、みんな今日までMySQLを使い続けてきたわけだしな。つまり……このバグはみんなが思うほど致命的なものじゃなかったってことだよ。実際、バグなんてそんなもんだろ。