特に、必要な機能が不足している場合(たとえば、外部キーが不要な場合)、MyISAMとInnoDBのどちらをどのように選択しますか。
それは常に両方を試し、測定することに帰着しますか?または、読み取りと書き込みの数と頻度、およびそのような他の測定値に関する経験則はありますか?テーブルのサイズは、一般的な選択に影響を与えますか?
答えは、常に、できれば自分のデータとワークロードを使用して、可能な限り測定する必要があるということです。
データアクセスパターンはアプリごとに大きく異なる可能性があるため、言うのは難しく、すべてのワークロードに「最適な」ストレージエンジンを決定することはおそらく不可能です。
ただし、先週MySQLConf/Percona Performance Confに参加したことで、MySQLスペースには非常に有望な開発があります。
代替ストレージエンジンのいくつか:
さらに、Percona、Googleなどは、InnoDBのパフォーマンスに大いに役立つパッチを提供しています。個人的には、OurDeltaビルドを実行しています。それは私にとってうまく機能し、OurDeltaとPerconaのビルドをチェックすることをお勧めします。
単純なストア/レポートシステムの場合は、生のパフォーマンスのためにMyISAMを使用します。
行レベルのロックを利用するために、大量の書き込みを伴う複数の同時アクセスが心配な場合は、InnoDBを使用します。
さまざまなMySQLデータベースエンジン用のベンチマークが数多くあります。 Percona MySQL Performance Blog にMyISAM、InnoDB、Falconを比較したまともなものがあります。 ここ を参照してください。
前述の2つのエンジン(MyISAMとInnoDB)の間で考慮すべきもう1つのことは、ロックへのアプローチです。 MyISAMはテーブルロックを実行し、InnoDBは行ロックを実行します。実にパフォーマンスの数値だけでなく、考慮すべきさまざまなことがあります。
アプリケーションが絶対に必要としない場合でも、運用上の理由から非常に便利な機能があります。
したがって、外部キーの制約にもかかわらず、とにかくInnoDBを使用することをお勧めします。
もちろん、これはServerFaultであり、Stack Overflowではないため、適切な答えは次のとおりです。
私のホスティングプロバイダーは、それが不可能でない限り、MyISAMを完全に取り除き、InnoDBに切り替えるようにアドバイスしました。
私たちの場合、深刻なデータ破損が発生し、1日に数回から数回表示され始め、常にREPAIR TABLEと関連コマンドが必要になり、大きなテーブルでは時間がかかりました。
InnoDBに変換(または変換)すると、問題はすぐに解消されました。私たちが持っていた欠点/警告:
ただし、これはすべて私たちの環境などに固有であるため、通常は適用されない場合があります。