0

約 220 万行のテーブルがあり、そのテーブルでいくつかの結合を使用してクエリを取得しようとしています。これらの結合の 1 つがサブクエリです。アプリのコードを完全に書き直さない限り、可能な限り最適化しました。

EXPLAIN()この特定のクエリの結果は次のとおりです。

私の説明クエリ

赤で強調表示したように、クリック テーブルには多数のレコードが含まれています。行 #4 は私のサブクエリ結合ですが、独自のテストを実行すると、その巨大なテーブルが遅さの原因になっているようです。

したがって、このクエリを実行したときに、Amazon CloudWatch でプロビジョニングされた IOPS とレイテンシーを確認しています。

クラウドウォッチ

これを見て、さらにプロビジョンド IOPS が必要であると言えるでしょうか? 今のところ1000しかありません。

ここで他に何をすべきか本当に知っています。

私も疑問に思っています-このRDSにリードレプリカがあります。メインDBが本番環境のパフォーマンスに影響を与えないように、キュー内のリードレプリカでこのクエリを実行することは理にかなっていますか?

4

1 に答える 1

0

リードレプリカを作成し、これらの長いクエリをすべてそこにオフロードすることにしました。

これらのクエリのほとんどはクライアント レポート用であり、クライアントが DB で多くのクリックを行うと、ページが長時間実行され、最終的にタイムアウトになりました。そこで、このリード レプリカを使用して、cron ジョブを使用してレポート キュー システムを作成しました。その場でレポートを提供する代わりに、それをキューに入れ、リードレプリカから準備ができたらメールで送信します。問題が解決しました！私は願います。

于 2014-07-01T14:31:00.193 に答える