MySQLで「エンジン」を意識しなくなった理由
昔のMySQLの解説記事を読むと、必ず出てくる言葉があります。
「テーブルエンジン」
- MyISAM
- InnoDB
この2つを選ぶのがMySQLの基本でした。
ところが最近のMySQLでは、エンジンを選ぶ話題自体をほとんど聞きません。
理由は単純です。
InnoDBが標準になったからです。
現在、新しくテーブルを作ると自動的にInnoDBになります。
しかし、これは最初からそうだったわけではありません。
MyISAMが標準だった時代
MySQLの初期バージョンでは、標準エンジンはMyISAMでした。
当時のMySQLは「高速な軽量データベース」という位置づけでした。
MyISAMの特徴はシンプルです。
- とにかく速い
- 構造が単純
- トランザクションがない
ここで重要なのがトランザクションです。
例えば銀行振込を考えます。
- Aの残高を減らす
- Bの残高を増やす
この2つは必ず同時に成功しなければなりません。
しかしMyISAMにはその仕組みがありませんでした。
つまり途中でサーバが落ちると、
片方だけ成功する可能性があります。
InnoDBの登場
InnoDBはこの問題を解決するために導入されました。
特徴は次の通りです。
- トランザクション対応
- ロールバック可能
- 行ロック
- 外部キー制約
つまり、現在私たちが「RDBMSらしい」と感じる機能の多くはInnoDBの機能です。
START TRANSACTION; UPDATE accounts SET balance = balance - 1000 WHERE id = 1; UPDATE accounts SET balance = balance + 1000 WHERE id = 2; COMMIT;
この処理はInnoDBでのみ安全に動作します。
なぜ最初からInnoDBではなかったのか
理由は性能と歴史です。
初期のInnoDBは重く、メモリ消費も大きく、
当時のハードウェアでは扱いにくいものでした。
一方MyISAMは軽量で高速でした。
Webサイトの用途（掲示板・ブログ）には十分でした。
つまり当時は、MyISAMの方が現実的な選択でした。
標準が変わったタイミング
大きな転換点は MySQL 5.5 です。
このバージョンからInnoDBがデフォルトエンジンになりました。
これは単なる設定変更ではありません。
MySQLの思想が変わった瞬間です。
それまでは「速いDB」
それ以降は「安全なDB」へと位置づけが変わりました。
何が変わったのか
InnoDBが標準になって、次のことが当たり前になりました。
- 自動クラッシュリカバリ
- データ整合性
- 外部キー制約
- 同時更新の安全性
現代のWebサービスでは必須の機能です。
逆に言うと、MyISAM時代はこれらが保証されていませんでした。
MyISAMが使われ続けた理由
それでも長い間MyISAMは残りました。
理由は互換性と速度です。
特に検索用途ではMyISAMが好まれました。
- カウントが速い
- シンプルな構造
- 移行コストが高い
既存システムでは変更が難しく、
長期間使われ続けることになりました。
リスクと注意点
古いシステムでは、まだMyISAMテーブルが残っていることがあります。
次の問題が起きます。
- 外部キーが効かない
- トランザクションが効かない
- ロック競合
- サーバ停止時の破損
特に怖いのがテーブル破損です。
MyISAMはクラッシュに弱く、修復が必要になることがあります。
CHECK TABLE users; REPAIR TABLE users;
このような運用が必要だった時代もありました。
今でもMyISAMを使う場面はあるか
完全にゼロではありません。
- 一時データ
- 読み取り専用データ
- 特殊な全文検索
ただし通常のWebアプリではInnoDBが前提です。
意図せずMyISAMを使うことの方が問題になります。
なぜこの変更が重要なのか
InnoDBが標準になったことで、
開発者は「データの安全性」を意識しなくてもよくなりました。
しかし逆に言えば、
古いMySQLの知識がそのまま通用しなくなったとも言えます。
MySQLは昔と同じ名前でも、内部の前提は変わっています。
エンジンを選ばなくなったのは、単に簡単になったからではありません。
データベースとしての役割が、
「高速な保存装置」から「整合性を保証するシステム」へ変化した結果です。
