MySQLデータベースエンジンをどのように選択しますか
特に、必要な機能が不足している場合（たとえば、外部キーが不要な場合）、MyISAMとInnoDBのどちらをどのように選択しますか。
それは常に両方を試し、測定することに帰着しますか？または、読み取りと書き込みの数と頻度、およびそのような他の測定値に関する経験則はありますか？テーブルのサイズは、一般的な選択に影響を与えますか？
答えは、常に、できれば自分のデータとワークロードを使用して、可能な限り測定する必要があるということです。
データアクセスパターンはアプリごとに大きく異なる可能性があるため、言うのは難しく、すべてのワークロードに「最適な」ストレージエンジンを決定することはおそらく不可能です。
ただし、先週MySQLConf/Percona Performance Confに参加したことで、MySQLスペースには非常に有望な開発があります。
代替ストレージエンジンのいくつか：
- XtraDB（InnoDBのフォーク）
- InnoDBプラグイン
- PBXT
- 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には自動回復機能があります。つまり、クリーンでないシャットダウン後のREPAIRTABLE操作に時間がかかることはありません。
- InnoDBを使用すると、リーダーがライターをブロックすることはなく、その逆も同様です。つまり、（一般的に言えば）同時実行性が高くなります（ただし、一般的な場合、パフォーマンスが向上する必要はありません）。
- InnoDBは、その行を主キーにクラスター化します。これは、主キーが十分に選択されている場合、読み取り操作のIO操作が少なくなることを意味する場合があります。
したがって、外部キーの制約にもかかわらず、とにかくInnoDBを使用することをお勧めします。
もちろん、これはServerFaultであり、Stack Overflowではないため、適切な答えは次のとおりです。
- アプリケーション開発者が選択したエンジンを常に使用する必要があります
- 特定のエンジンを選択していない場合、MySQLの使用についてはそれほど真剣ではなく、おそらくそれを適切に使用する方法を知りません。
- アプリケーションがテストされたエンジンとは別のエンジンに切り替えることはできません。バグが発生する可能性があります。
私のホスティングプロバイダーは、それが不可能でない限り、MyISAMを完全に取り除き、InnoDBに切り替えるようにアドバイスしました。
私たちの場合、深刻なデータ破損が発生し、1日に数回から数回表示され始め、常にREPAIR TABLEと関連コマンドが必要になり、大きなテーブルでは時間がかかりました。
InnoDBに変換（または変換）すると、問題はすぐに解消されました。私たちが持っていた欠点/警告：
- FULLTEXTインデックスを持つテーブルを変換できません（この問題は時間の経過とともに解消されました。とにかく品質がはるかに高いSolr/Luceneベースのソリューションに置き換えられました）
- COUNT（*）を必要とすることが多い数百万行の大きなテーブルは非常に遅いので、それらを切り替えることもできませんでした。
ただし、これはすべて私たちの環境などに固有であるため、通常は適用されない場合があります。