最終更新:2011-02-26 (土) 04:38:00 (4798d)  

MySQL/ストレージエンジン
Top / MySQL / ストレージエンジン

  • MyISAM - テーブル単位のファイルによるデータ構造を持ち、トランザクション機能をサポートしていない(MySQL標準)
  • InnoDB - 行ロックとトランザクションをサポート
  • Memory? - メモリ上にテーブルを配置する
  • Merge? - 複数のMyISAMテーブルを統合する
  • Archive? - 圧縮したデータベースを使用する
  • FEDERATED - リモートのデータベースを参照する
  • NDB? - クラスター構成にて使用される
  • CSV - データファイルにCSVを使用する
  • Blackhole - ダミーテーブルを使用する
  • MySQL Cluster - 負荷分散型・高可用性のリアルタイムデータベース
  • Spider

MyISAM

↑

利点

  • WHERE条件無しのSELECT COUNT(*)が一瞬で返る
    • (InnoDBの場合はテーブルをなめる必要がある)
  • メモリにおさまらないほど巨大なテーブルのフルテーブルスキャン系の処理効率が良い
    • (InnoDBではこうしたバッチ処理でバッファプールの中身が追い出されてしまうし、バッファプールの管理オーバーヘッドもあるが、MyISAMは専用のバッファプールを持たないので効率が良い)
  • OSコピーによってテーブルの移動が極めて簡単にできる
  • MERGEテーブルを使うことができる (InnoDBでも5.1のレンジパーティショニングを使えば十分なことは多い)
  • リードオンリーのテーブルであれば圧縮できる
  • ALTER TABLE ENABLE/DISABLE KEYSを使える。例えばインデックスなしの状態で高速にロードして、後からインデックスを有効化とかができる (InnoDB Pluginではインデックス単位の再構築ができるのでかなり緩和できる)
  • InnoDBはテーブルのオープン処理がシリアライズされるため、大量の数のテーブルを初回オープンするような処理がきつい
↑

ソリューションによって緩和できるもの

  • クラッシュ時に壊れる問題やリカバリ(REPAIR TABLE)の遅さは、生きているスレーブを使って復旧すれば解決できる
  • テーブルが巨大になることで引き起こされる性能問題は、小さなテーブルに分割することで解決できる
↑

InnoDB

↑

利点

  • 障害対応系
    • クラッシュしても再起動するだけでリカバリができる
    • クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある)
    • オンラインバックアップ?ができる
    • INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い
  • 性能系
    • 行レベルロック?なので並列性が高い(MyISAMはテーブルロック?)。またSELECTと更新系SQL文が競合しない。
    • 主キー検索が高速 (クラスタ索引?のため)
    • ダイレクトI/O(innodb_flush_method=O_DIRECT)を使えるためキャッシュ効率が高い
    • インデックスの追加/削除をするにあたってテーブルを再編成する必要がなく、そのインデックスけを再構築するので効率が良い(InnoDB Plugin)
    • Insert Bufferという仕組みにより、セカンダリインデックスへのINSERT処理の効率がMyISAMよりも良い
↑

従来は欠点だったが、InnoDB Pluginによって改善されたもの

  • グループコミットが無効化されるため同時更新性能が著しく低下していた
  • I/Oスレッドが事実上読み書き1本ずつしか無かったため並列性が低く、RAIDやSSDを有効活用できなかった
  • CPUスケーラビリティが悪く、4CPUコアくらいまでしかスケールしなかった
  • 同じ量のデータを投入してもテーブルサイズがMyISAMよりも倍以上大きくなることがある(InnoDB Pluginの圧縮機能を使うことで緩和する手がある)
↑

ほか

  • InnoDBでは外部キーが使える
↑

MyISAMとInnoDBのどちらを使うべきか

↑

参考




検索：