MySQLデータベースエンジンの選択方法

特に、MyISAMとInnoDBのどちらも必要な機能が欠けている場合（外部キーが不要な場合など）、どのように選択しますか。

常に両方を試して測定することになりますか？または、読み取りと書き込みの数と頻度、およびそのような他の尺度に関して、良い経験則がありますか？テーブルのサイズは、一般的な選択に影響を与えますか？

答えは、可能な限り、できれば独自のデータとワークロードを使用して、常に測定する必要があるということです。

データアクセスパターンはアプリごとに大きく異なる可能性があるため、すべてのワークロードに「最適な」ストレージエンジンを決定することは不可能であり、おそらく不可能です。

ただし、先週MySQLConf / Percona Performance Confに参加したMySQL分野では、非常に有望な開発が行われています。

代替ストレージエンジンの一部：

1. XtraDB（InnoDBのフォーク）
2. InnoDBプラグイン
3. PBXT
4. TokuDB

さらに、Percona、Googleなどは、InnoDBのパフォーマンスを大幅に向上させるパッチを提供しています。個人的に、OurDeltaビルドを実行します。私にとってはうまくいきます。OurDeltaとPerconaのビルドをチェックすることをお勧めします。

単純なストア/レポートシステムだけの場合、MyISAMをそのままのパフォーマンスで使用します。

行レベルのロックを活用するために、大量の書き込みを伴う複数の同時アクセスが懸念される場合は、InnoDBを使用します。

さまざまなMySQLデータベースエンジンについて、かなりの数のベンチマークがあります。Percona MySQL Performance BlogにMyISAM、InnoDB、およびFalconを比較したまともなものがあります。こちらを参照してください。

前述の2つのエンジン（MyISAMとInnoDB）の間で考慮すべきもう1つのことは、ロックへのアプローチです。MyISAMはテーブルロックを実行し、InnoDBは行ロックを実行します。率直なパフォーマンスの数値だけでなく、さまざまな考慮事項があります。

アプリケーションで絶対に必要としない場合でも、操作上の理由で非常に役立つ機能があります。

• InnoDBにはMVCCがあるため、ノンブロッキングの一貫性のあるバックアップを作成できます
• InnoDBには自動回復機能があります。これは、クリーンシャットダウン後の長いREPAIR TABLE操作はありません
• InnoDBでは、リーダーがライターをブロックすることはなく、その逆もありません。つまり、（一般的に言えば）並行性が向上することを意味します（ただし、これは一般的なケースでパフォーマンスを向上させる必要はありません）
• InnoDBはその行を主キーにクラスター化します。これは、主キーが十分に選択されている場合、読み取り操作のIO操作が少なくなることを意味する場合があります。

したがって、外部キーの制約にもかかわらず、おそらくInnoDBを使用したいと思うでしょう。

もちろん、これはStackOverflowではなくServerFaultなので、適切な答えは次のとおりです。

• アプリケーション開発者が選択したエンジンを常に使用する必要があります
• 特定のエンジンを選択していない場合、MySQLの使用についてそれほど深刻ではなく、おそらく適切に使用する方法を知らないでしょう。
• アプリケーションがテストされたエンジンとは異なるエンジンに切り替えることはできません。バグが発生する可能性があります。

ホスティングプロバイダーは、不可能でない限り、MyISAMを完全に削除し、InnoDBに切り替えることを勧めました。

私たちの場合、1日に数回から数回表示されるようになった深刻なデータ破損があり、常にREPAIR TABLEと関連するコマンドが必要であり、大きなテーブルでは時間がかかりました。

InnoDBに変換（または変換された）すると、問題はすぐになくなりました。マイナス面/注意点：

• FULLTEXTインデックスを使用してテーブルを変換することはできません（この問題は時間が経つにつれて解消されました。Solr/ Luceneベースのソリューションに置き換えられましたが、いずれにしても品質ははるかに優れています）
• 多くの場合COUNT（*）を必要とする数百万行の大きなテーブルは非常に遅いため、それらを切り替えることもできませんでした。

ただし、これはすべて環境などに固有であるため、通常は適用されない場合があります。