MySQLはいつRDBMSらしくなったのか

MySQL InnoDB ACID SQLモード データベース史

MySQLは最初からRDBMSだったわけではない

現在のMySQLは、他のデータベースと同じようにトランザクションや整合性を重視するRDBMSとして扱われています。
しかし、最初からそうだったわけではありません。

むしろ長い間、MySQLは「データベースっぽい保存装置」として使われていました。
それでも問題にならなかったのは、用途が現在と大きく違っていたためです。

今の感覚で過去のMySQLを見ると誤解します。
「機能が足りなかった」のではなく、「目的が違っていた」のです。

初期MySQLの実態：トランザクションがない

初期のMySQLで最も象徴的なのが、MyISAMストレージエンジンです。
当時のデフォルトでした。

MyISAMには次の特徴があります。

  • トランザクションがない
  • 外部キー制約がない
  • ロールバックできない

つまり、現在のRDBMSの重要機能が存在していませんでした。

例を挙げます。

UPDATE accounts SET balance = balance - 1000 WHERE id = 1;
UPDATE accounts SET balance = balance + 1000 WHERE id = 2;

途中でサーバが落ちた場合、片方だけ成功します。
銀行システムでは致命的ですが、当時の用途では問題になりにくかったのです。

なぜそれで成立していたのか

当時の主な用途は次の通りでした。

  • 掲示板
  • コメント
  • カタログ表示
  • アクセスログ

これらは多少の不整合があってもサービスが成立します。
「書き込みが1件欠けた」程度なら許容されていました。

その代わりMyISAMは非常に高速でした。
読み込み性能が高く、レンタルサーバでも軽快に動作しました。

つまりMySQLは、整合性より速度を優先した設計だったのです。

転機：InnoDBの標準化

MySQLがRDBMSらしくなった最大の転換点は、InnoDBの採用です。

InnoDBには次の機能があります。

  • トランザクション
  • ロールバック
  • 外部キー制約
  • 行ロック

これにより「途中で止まると壊れる」問題が解決します。

先ほどの送金処理は、次のように扱われます。

START TRANSACTION;
UPDATE accounts SET balance = balance - 1000 WHERE id = 1;
UPDATE accounts SET balance = balance + 1000 WHERE id = 2;
COMMIT;

途中で障害が起きればROLLBACKされます。
ここで初めて、業務システムでも使える性質を持ちます。

MySQL5.5以降、InnoDBがデフォルトになりました。
この時点からMySQLの性格は大きく変わります。

ACID特性の導入

InnoDBにより、MySQLはACID特性を意識するデータベースになります。

ACIDとは次の4つです。

  • Atomicity（原子性）
  • Consistency（一貫性）
  • Isolation（独立性）
  • Durability（永続性）

これはRDBMSの中心概念です。
ここからMySQLは「高速なWeb用DB」から「業務用DB」に変わっていきます。

それでも残っていた“昔の挙動”

ただし、ストレージエンジンが変わっても挙動は完全には変わりませんでした。
SQLの解釈は依然として寛容でした。

  • 曖昧なGROUP BY
  • 型の自動変換
  • ゼロ日付

つまり内部はRDBMSでも、表面は従来のMySQLのままでした。
これが後の移行問題の原因になります。

第二の転換点：MySQL5.7

本当の意味でRDBMSらしくなったのは、5.7以降です。
SQLモードの変更が行われました。

主な変化です。

  • ONLY_FULL_GROUP_BYの有効化
  • STRICTモードの有効化
  • 不正日付の拒否

ここで初めて、SQLの解釈が標準に近づきます。

つまり

5.5

  • 内部構造がRDBMS化（InnoDB）

5.7

  • 挙動がRDBMS化（SQL解釈）

この2段階でMySQLは変わりました。

なぜ変化が必要だったのか

理由は利用範囲の拡大です。
MySQLは次の領域で使われるようになりました。

  • EC基幹
  • 会計連携
  • SaaS
  • 金融系サービスの一部

ここではデータの一貫性が重要です。
「だいたい正しい」は許されません。

そのためMySQLは、互換性より整合性を選びました。

移行時に起きる混乱

古いシステムはMyISAM時代の前提で設計されています。

  • ロールバックを考慮しない処理
  • 外部キーなし前提の削除
  • 順序依存のSELECT

新しいMySQLでは問題が表面化します。
アプリケーションのバグのように見えますが、設計思想の差です。

まとめ

MySQLがRDBMSらしくなったのは一瞬ではありません。
段階的な変化でした。

  • InnoDBで内部が変わり
  • SQLモードで外部挙動が変わりました

現在のMySQLは、初期のMySQLとは別物に近い性格を持っています。
バージョンアップでトラブルが起きるのは、その変化が小さな修正ではないからです。

MySQLの歴史は、単なる機能追加の歴史ではありません。
「使いやすさ」と「正しさ」のバランスを調整してきた過程でもあります。

そして移行作業とは、データベースを更新する作業というより、システムがどの時代の前提で作られていたかを確認する作業になります。