「ベストプラクティス」は次のとおりです。
- パフォーマンスを測定し、関連するサブシステムを可能な限り分離します。
- ボトルネックの根本原因を特定します。 I / Oバウンドですか？ CPUバウンド？メモリバウンド？ロックを待っていますか？
- 発見した根本的な原因を軽減するために変更を加えます。
- もう一度測定して、ボトルネックを修正したことを示し、どれだけ 。
- 手順2に進み、システムが十分に高速になるまで必要に応じて繰り返します。
http://www.mysqlperformanceblog.com でRSSフィードを購読します。 歴史的な記事も読んでください。これは、パフォーマンス関連の知恵にとって非常に役立つリソースです。たとえば、InnoDBとMyISAMについて質問しました。彼らの結論：InnoDBのパフォーマンスは平均してMyISAMよりも約30％高くなっています。 MyISAMがInnoDBよりも優れている使用シナリオもいくつかあります。
そのブログの著者は、@AndrewBarnettが言及した本「HighPerformanceMySQL」の共著者でもあります。
@ʞɔıuからのコメント：I / OバウンドかCPUバウンドか、メモリバウンドかを判断する方法はプラットフォームに依存します。オペレーティングシステムは、ps、iostat、vmstat、topなどのツールを提供する場合があります。または、OSがサードパーティのツールを提供していない場合は、サードパーティのツールを入手する必要がある場合があります。
基本的に、100％の使用率/飽和度でペグされているリソースがボトルネックになる可能性があります。 CPU負荷は低いが、ハードウェアのI / O負荷が最大である場合は、I/Oバウンドになります。
ただし、これは1つのデータポイントにすぎません。救済策は他の要因にも依存する可能性があります。たとえば、複雑なSQLクエリがファイルソートを実行している可能性があり、これによりI/Oがビジー状態になります。より多くの/より高速なハードウェアを投入する必要がありますか、それともファイルソートを回避するためにクエリを再設計する必要がありますか？
StackOverflowの投稿にまとめるにはあまりにも多くの要因があり、この主題に関する多くの本が存在するという事実がこれを裏付けています。データベースを効率的に運用し、リソースを最大限に活用することは、専門的なスキルと絶え間ない研究を必要とするフルタイムの仕事です。
Jeff Atwoodが、システムのボトルネックを見つけることについてのすばらしいブログ記事を書いたところです。