確実にアプリケーションとデータベースのベンチマークを行い、ボトルネックを検出しておく必要があります。これを修正 (または、ボトルネックを 「dummy」に置換) することによって、次のボトルネック (など) の確認が容易になります。現在のアプリケーションの総合的なパフォーマンスが許容できるものであっても、実際にパフォーマンスの強化が迫られる場合に備えて、少なくともボトルネックそれぞれに対して計画を立て解決方法を判定しておく必要があります。
移植可能なベンチマークプログラムの例として、MySQL ベンチマークスィートを取り上げます。詳しくは項4.1.4. 「MySQL ベンチマークスィート」を参照してください。このスィートから任意のプログラムを選び、必要に合わせて修正することができます。これによって、それぞれの問題に対して複数の解決方法を試行して、実際にもっとも高速が得られるのはどれであるかについてテストすることができます。
これ以外の無料のベンチマークスイートに Open Source Database Benchmark があり、これは http://osdb.sourceforge.net/ で入手できます。
一般的には、システムの負荷が非常に高い状況にのみ問題が発生します。負荷の問題が (テスト済の) 本稼働のシステムで発生したと問い合わせてくる顧客が多数いました。ほとんどの場合、パフォーマンスに関わる問題は、高負荷時のテーブルスキャンの不良などデータベースの基本的な設計上の問題か、オペレーティングシステムやライブラリの問題が原因だと判明しています。たいていは、システムがまだ本稼働に入っていない場合のほうが問題の修正がはるかに容易です。
このような問題を回避するには、想定可能な最悪の負荷でアプリケーション全体のベンチマークにある程度力を注ぐ必要があります。
複数のクライアントが同時にクエリーを発行したときに生じる高負荷状態をシミュレートするには、mysqlslap プログラムが効果的です。項3.7. 「mysqlslap — クライアント負荷エミュレーション」 を参照してください。
Super Smack も試してください。これは http://jeremy.zawodny.com/mysql/super-smack/ で入手できます。
その名 (Smack = 打ちこわし) のとおり、システムに限界まで負荷をかけることができるため、必ず開発システムでのみ使用するようにしてください。