2

私のウェブサイトは、アクセスのピーク時に深刻な問題を抱えています。多くのトラブルシューティングを行った後、問題はデータベースにあることがわかりました。

データのテーブルを取得する Index で実行されるこのメイン クエリがあります。

忙しい日には、サイトの初回読み込みに 30 ～ 45 秒かかりますが、その後は毎回約 5 分間非常に高速に読み込まれ、その後再び速度が低下し、最終的に負荷がかかりすぎてサイトがダウンします。

データベースで直接クエリをテストしたところ、まったく同じように実行されました。

これは、クエリまたは MySQL 構成と関係がありますか?

返される結果が小さい場合は完全に正常に機能しますが、リストが非常に大きい忙しい日には、サイトが実際に遅くなり、停止します.

編集：

すべての提案に感謝します。

一部の名前が適切ではなかったため、クエリを少し修正し、DB に修正を加えました。

すべての提案の後、クエリを変更して、ワイルドカード検索と、不要になったテーブルへの冗長なリクエストを削除しました。

クエリ自体は次のとおりです。

SELECT g.id, g.`name`, g.scores, g.sportFK, g.`desc`, g.`date`, s.id AS streamid
       FROM games AS g
       LEFT JOIN streams AS s ON s.gameFK = g.id
             WHERE
                  (g.date >= '" . $date . "' AND g.date <= '" . $newdate . "') 
                  AND g.sportFK IN (" .  $sportfk . ") 
                  ORDER BY g.date ASC"

これをテストした後、クエリの最初のパフォーマンスはまだ 33 秒で実行されており、その後のすべての実行は 0.04 秒で実行されています。これは、ピーク時が来てもサイトへの影響が同じであることを示唆しています。

から要求された情報も準備しましたEXPLAIN。

これは「GAMES」テーブル用です

ゲームテーブル

GAMES TABLE:

SIZE: 6MB
ROWS: 14841
TYPE: INNODB

これは「STREAMS」テーブル用です

ストリーム テーブル

STREAMS TABLE:

SIZE: 80MB
ROWS: 135296
TYPE: MyISAM

編集：マーティンは、書き込みについて指摘してくれてありがとう. この DB は別のソースからも一定の間隔で読み込まれるため、一定の READ 操作と WRITE 操作が発生します。これについては、もう少し研究する必要があります。

4

3 に答える 3

1

おそらく、最初にクエリを実行するときの余分な時間が、クエリのコンパイルと実行計画の作成に費やされている可能性があります。これはしばらくキャッシュされたままになり、その後再び発生します。

解決策は、クエリをストアド プロシージャに入れることです。

于 2013-08-19T19:21:18.343 に答える
1

さて、このクエリは、すべての DB 開発者にとってパフォーマンスの恐怖に違いありません :-)

クエリのコンパイルと実行計画の計算のために、最初の時間が長くなる可能性があります。を使って見ることができますEXPLAIN。

動作が 5 分で繰り返されるため、インデックス自体または欠落しているインデックスに問題があるはずです。

Web サイトの負荷内で読み取りのみが行われるか、(クエリを使用して)書き込みと共に同時読み取りが行われるかを指定する必要があります。

書き込み操作も実行すると、インデックスの再計算が開始されます。もう 1 つの考えられる問題は、ロックです。5分ごとに誰かがデータを書き込むとしましょう。クエリは非常に複雑であるため、書き込みトランザクションのためにテーブルをロックする必要があり、読み取りはコミット/ロールバックまで待機します。

このクエリは非常に複雑であり、決して高速ではないことに注意してください。つまり、非常に高速です。

  • インデックスを使用して別のテーブルにカウントがあります
  • 大きな条件を持つ別のテーブルへの1つの結合 - 結合自体が遅いポイントです
  • 2 つの where 句 => 2 つのインデックス
  • 別のインデックスを使用して注文する

いくつかのインデックスがあることがわかります。書き込み操作は、テーブルとインデックスをロックして更新するだけで、そのうちの 5 つがあります。内側のカウントも良くありません。

本当に優れたパフォーマンスが必要な場合、または古典的なアプローチを定義する場合は、DB またはドメインの設計を改善することをお勧めします。そしてそれを再設計するよりも。

于 2013-08-20T07:47:16.730 に答える
0

クエリが複数回実行された場合にパフォーマンスを向上させるために、データベースの内部にキャッシュがあるのは正常です。パフォーマンスを向上させたい場合は、説明計画を取得して、データベース構造を改善するか、クエリ構造を改善する必要があります。

データベースを改善するには、説明計画を確認し、全文スキャンのような高価な操作がないことを確認してください。たとえば、g.name と結合列にインデックスを追加した場合の影響を確認したいと思うでしょう。コストの改善を確認しながら、インデックスを追加してみてください。書き込みが遅く、データベースのサイズが大きくなるため、インデックスの追加には注意してください。

于 2013-08-19T19:24:25.787 に答える