なぜ昔のMySQLはいい加減だったのか

昔のMySQLは本当に“いい加減”だったのか

古いMySQLの話をすると、よく「昔のMySQLはいい加減だった」と言われます。
確かに現在のMySQLや他のRDBMSと比べると、かなり寛容な挙動をしていました。

間違ったSQLでも実行される。
型が違っても保存される。
不正な日付も受け付ける。

ただし、これは欠陥だったわけではありません。
当時のMySQLは、そもそも違う問題を解決するために作られていました。

MySQLが生まれた時代の前提

MySQLが広まり始めた1990年代後半から2000年代初頭、Web開発の状況は現在とは大きく異なっていました。

• CGIが主流
• PHPはテンプレート言語に近い使われ方
• 個人サイトが中心
• サーバは共用レンタルサーバ

重要だったのは、専門のDBAがいなくても使えるデータベースであることです。

当時の商用データベースは扱いが難しく、設定も運用も重いものでした。
小規模なWebサイトにとっては現実的ではありません。

そこで求められたのが「簡単に動くデータベース」です。
MySQLはその需要に合わせて設計されました。

設計思想：止まらないことが最優先

現在のRDBMSは、整合性や正確性を重視します。
一方、当時のWebサイトで最も困るのは「止まること」でした。

掲示板が投稿できない。
カートに商品が入らない。
ログインできない。

これらは売上や運営に直結します。

そのためMySQLは、不正な入力を拒否するより処理を継続する設計を選びました。

例です。

INSERT INTO users (age) VALUES ('abc');

昔のMySQLはこれをエラーにしません。
0として保存します。

不正データは入りますが、サイトは止まりません。
当時はこの挙動が歓迎されました。

GROUP BYの曖昧さ

もう一つ象徴的なのがGROUP BYです。

SELECT id, name
FROM users
GROUP BY id;

標準SQLでは不正です。
しかし昔のMySQLは実行し、結果を返しました。

理由は単純です。
多くのWebアプリが、この書き方で動いていたからです。

開発者はSQLを厳密に理解しているとは限りません。
それでもサイトが作れることが重要でした。

MySQLは「正しさ」より「使いやすさ」を優先しました。

ゼロ日付とNULL

古いMySQLの特徴として、ゼロ日付があります。

INSERT INTO orders (created_at) VALUES ('0000-00-00');

現在のRDBMSでは許されません。
しかし当時は便利でした。

未確定の日時
仮登録ユーザー
下書きデータ

こうした状態を表現するために使われていました。
NULLの扱いが難しかった時代背景もあります。

なぜ問題にならなかったのか

「それでデータは壊れなかったのか」と思うかもしれません。
実際には、大きな問題になるケースは限定的でした。

理由はシンプルです。
扱うデータが比較的単純だったからです。

• コメント
• 投稿
• 会員情報
• 商品一覧

会計や在庫管理のような厳密さは要求されていませんでした。
多少の曖昧さがあっても運用できました。

変化：Webが業務システムになった

状況が変わったのは、Webアプリが業務システムとして使われ始めてからです。

• 受注管理
• 在庫管理
• 決済連携
• 請求管理

ここでは曖昧なデータは許されません。
「だいたい合っている」では困ります。

この要求に応えるため、MySQLは方向転換します。
厳格化です。

いい加減だったのではなく、役割が違った

現在の視点から見ると、昔のMySQLは確かに緩いです。
しかし当時の目的から見ると合理的でした。

• DBAがいなくても使える
• 設定が簡単
• エラーで止まらない

この特徴が、Webの普及を支えた面もあります。

もし最初から厳密なRDBMSしか存在しなかった場合、個人サイトや小規模サービスはもっと作りにくかったはずです。

現在との違い

現在のMySQLは次の点が変わっています。

• 不正SQLを拒否
• 不正データを拒否
• 標準SQLに近い挙動

つまり、昔のMySQLの思想は「アプリケーション寄り」、現在は「データ寄り」です。

移行時に起きる誤解

古いシステムを新しいMySQLへ移行すると、多くの開発者はこう感じます。

「MySQLが厳しくなって使いにくくなった」

実際には逆です。
以前はデータベースがアプリの問題を吸収していました。
現在は吸収しなくなっただけです。

その結果、隠れていた設計上の問題が表面化します。

まとめ

昔のMySQLはいい加減だったわけではありません。
当時のWeb開発に最適化されたデータベースでした。

現在のMySQLは、業務システムでも使えるように変化しています。
その過程で、曖昧な挙動が削られました。

バージョンアップで問題が起きるのは、ソフトの品質が下がったからではありません。
過去に許されていた前提が、明文化されただけです。

そして移行作業は、単なるDB更新ではなく、システムがどの程度「曖昧さ」に依存していたかを確認する作業になります。