かつて主役だったMyISAMが見なくなった理由
昔のMySQLの資料には、必ずこう書かれていました。
「テーブルエンジンを選びましょう」
そのときの代表格が MyISAM です。
ところが現在のMySQLでは、MyISAMを意識する機会はほとんどありません。
新規にWebサービスを作っている人の中には、名前すら知らない場合もあります。
これは偶然ではありません。
使われなくなったのではなく、役割が終わったに近い状態です。
なぜMyISAMは消えたのか。
単に「InnoDBの方が高性能だから」では説明できません。
MyISAMは何が優れていたのか
MyISAMは非常にシンプルな設計です。
- 構造が単純
- 読み込みが高速
- 管理が軽い
特に「SELECTが速い」ことで評価されていました。
掲示板やブログの閲覧用途では十分な性能を発揮しました。
また、次の特徴がありました。
- テーブルカウントが即時
- ファイルコピーでバックアップ可能
SELECT COUNT(*) FROM articles;
MyISAMでは高速ですが、InnoDBでは遅くなることがあります。
この違いが当時は大きな利点でした。
しかし致命的な欠点があった
最大の問題は、トランザクションがないことです。
つまり次の保証がありません。
- 同時更新の安全性
- 途中失敗時の復元
- 一貫性の維持
例えば注文処理です。
- 在庫を減らす
- 注文履歴を書く
この途中で障害が発生すると、
在庫だけ減って履歴が残らない、という状態が起きます。
これはアプリのバグではなく、
データベースが保証していないだけです。
ロック方式の違い
MyISAMはテーブルロックです。
つまり、1人が書き込むと他の書き込みが待たされます。
一方InnoDBは行ロックです。
- MyISAM → テーブル全体をロック
- InnoDB → 変更行のみロック
ユーザー数が増えたWebサービスでは、これが致命的になります。
書き込みが増えるほど遅くなります。
クラッシュ耐性の問題
もう1つの大きな問題があります。
サーバ停止時の挙動です。
MyISAMはクラッシュに弱く、
電源断やプロセス停止でテーブルが壊れることがあります。
REPAIR TABLE articles;
この操作が必要になるケースがありました。
大規模サイトでは深刻な運用問題になります。
InnoDBはログベースのリカバリを行うため、
再起動時に自動復旧します。
Webの使われ方が変わった
MyISAMが消えた最大の理由は、性能ではありません。
Webアプリの性質が変わったことです。
昔のWeb：
- 読み取り中心
- 個人サイト
- 更新頻度が低い
現在のWeb：
- 書き込み中心
- SNS
- 同時アクセス多数
この変化で必要になったのが「整合性」と「同時処理」です。
MyISAMの設計思想と合わなくなりました。
なぜ完全に削除されないのか
MySQLからMyISAMが完全に消えたわけではありません。
理由は互換性です。
古いシステムではまだ使われています。
また、特殊な用途では利点もあります。
- 読み取り専用データ
- 一時テーブル
- 簡易ログ
ただし通常のアプリでは選択肢になりません。
注意点
古いデータベースを引き継ぐと、
一部のテーブルだけMyISAMということがあります。
次の問題が起きます。
- 外部キーが効かない
- トランザクションが効かない
- バックアップ整合性が取れない
特に mysqldump の実行中に更新があると、
不整合なバックアップが作られる可能性があります。
InnoDBに移行すべきか
基本的には移行した方が安全です。
ALTER TABLE articles ENGINE=InnoDB;
ただし注意があります。
大量データでは長時間ロックが発生します。
運用時間中に実行するとサービス停止につながる可能性があります。
MyISAMが消えた本当の理由
MyISAMは「劣っていた」わけではありません。
時代の要求に合わなくなったのが実態です。
昔のWebにとっては合理的な設計でした。
しかし現在のサービスでは、速度より整合性が重要になりました。
データベースの進化は性能向上だけではありません。
「何を保証するか」が変わった結果、MyISAMは役割を終えたと考えると理解しやすいです。
