4

のmySQLデータベーステーブルがありますproducts。データベースの負荷を軽減するためにキャッシュレイヤーを利用していますが、アプリケーションをさらに高速化するために、キャッシュレイヤーに格納する必要のある実際のデータを最小限に抑えることをお勧めします。

訪問者に表示されるデータベース内のすべての製品には、価格が付加されています。

価格は、と呼ばれる別のテーブルに保存されpricesます。各訪問者（顧客）が適用する割引レベルに応じて、複数の価格カテゴリがあります。時々、各製品の特別価格が利用可能であることを意味するキャンペーンがあります。特別価格は、というテーブルに保存されますspecials。

  • テーブルを結合する一時テーブルを作成するのは悪いことですか？

必要な情報だけがあり、もちろんキャッシュされます。

-------------|-------------|------------ 
| productId  |  hasPrice   | hasSpecial
-------------|-------------|------------ 
  1          |  1          | 0
  2          |  1          | 1

そうすることで、特定の製品が実際に価格を持っているかどうかを知るのが非常に簡単になります。製品をリストまたは提示するたびに、完全なpricesものまたは表を繰り返す必要はありません。specials

  • 一時テーブルはWebアプリケーションで一般的なものですか、それとも単に悪い設計ですか？
4

2 に答える 2

3

とにかくこのデータをキャッシュする場合、それは本当に一時テーブルにある必要がありますか? キャッシュを再構築する必要がある場合にのみクエリのオーバーヘッドが発生するため、一時テーブルは必要ない場合もあります。

于 2010-04-29T12:36:36.110 に答える
2

他のパフォーマンスの問題と同じようにアプローチする必要があります。必要なパフォーマンスの量を決定してから、ラボで実稼働グレードのハードウェアでテストを繰り返し実行します。不必要な最適化を行わないでください。

アプリのプロファイルを作成し、実行しているクエリが多すぎるのか、クエリ自体が遅いのかを確認する必要があります。Webアプリの速度低下のほとんどのケースは、クエリが非常に簡単であるにもかかわらず、（私の経験では）あまりにも多くのクエリを実行することによって引き起こされます。

通常、最良のエンジニアリングソリューションは、データベースを再構築し、場合によっては非正規化して、一般的な読み取りのユースケースで必要なクエリを少なくすることです。キャッシングも役立つ場合がありますが、必要なクエリが少なくなるようにリファクタリングするのが最適な場合がよくあります。

基本的に、書き込みよりも読み取りを多く行うことを計画している場合は、書き込みパスでの作業量を増やして、読み取りパスでの作業量を減らすことができます。

于 2010-04-30T22:11:33.427 に答える