クエリ ストアは、予測可能なワークロード パフォーマンスの追跡と維持が重要なさまざまなシナリオで使用できます。 次の例を考えてみましょう。
- コストの高いクエリを識別して調整する。
- また、 A/B テストを実行できます。
- 即興ワークロードを特定して改善する。
コストの高いクエリを識別して調整する
実行時間の長いクエリを特定する
実行時間が最も長いクエリをすばやく識別するには、サーバーの azure_sys データベースのクエリ ストア ビューを使用します。 このようなクエリは大量のリソースを消費する傾向があります。 実行時間が長いクエリを最適化すると、システムで他のクエリの実行に使用できるリソースが解放されるため、パフォーマンスを向上させることができます。
パフォーマンス向上の対象クエリ
クエリ ストアでは、パフォーマンス データが時間枠にスライスされるため、クエリのパフォーマンスを経時的に追跡できます。 この機能は、使用時間全体の増加に寄与しているクエリを正確に特定するのに役立ちます。 その結果、ワークロードのトラブルシューティングを行うことができます。
高コストのクエリを最適化する
パフォーマンスが最適ではないクエリを特定する際に行うアクションは、問題の性質によって異なります。 これらのアクションの一部を以下に示します。
- クエリで使用される基になるテーブルの統計が最新であることを確認します。
- コストが高いクエリを書き直すことを検討します。 たとえば、クエリのパラメーター化を利用し、アドホック SQL の使用を減らします。 アプリケーション側で行うのではなく、データベース側でのデータ フィルター処理の適用など、データを読み取るときに最適なロジックを実装します。
A/B テストを実行する
クエリ ストアを使用して、導入が計画されているアプリケーション変更の前後、または移行の前後で、ワークロードのパフォーマンスを比較します。 変更がワークロードのパフォーマンスに及ぼす影響をクエリ ストアを使用して評価するシナリオの例:
- PostgreSQL のメジャー バージョン間の移行。
- 新しいバージョンのアプリケーションの展開。
- サーバーに与えられるリソースの量の変更。
- サーバーの動作に影響を与えるパラメーターを変更する。
- 高コストのクエリによって参照されているテーブルでの欠落したインデックスの作成。
これらのどのシナリオでも、次のワークフローを適用します。
- 計画的な変更の前にクエリ ストアを使用してワークロードを実行し、パフォーマンスのベースラインを生成します。
- 制御された時点で必要な変更を適用します。
- 変更後のシステムのパフォーマンスを明確に把握できるように、十分な時間内にワークロードを実行し続けます。
- 変更の前と後の結果を比較します。
- 変更したままにするか、ロールバックするかを決定します。
即興ワークロードを特定して改善する
一部のワークロードには、アプリケーション全体のパフォーマンス向上のために調整できる支配的なクエリがありません。 このようなワークロードの特徴は、一般に、比較的多くの固有クエリが含まれ、各クエリがシステム リソースの一部を消費していることです。 個々の固有クエリの実行頻度は低いので、個別のランタイム消費量は重要ではありません。 一方で、アプリケーションが絶え間なく新しいクエリを生成していると、システム リソースのかなりの部分がクエリのコンパイルに費やされ、最適とはいえない状態になります。 通常、このような状況は、アプリケーションが (ストアド プロシージャまたはパラメーター化クエリを使用するのではなく) クエリを生成する場合、または既定でクエリを生成するオブジェクト リレーショナル マッピング フレームワークにアプリケーションが依存している場合に、発生します。
ユーザーがアプリケーションのコードを管理している場合は、ストアド プロシージャまたはパラメーター化クエリを使用するようにデータ アクセス層を書き直すことを検討できます。 ただし、このような状況は、データベース全体 (すべてのクエリ) またはクエリ ハッシュが同じ個々のクエリ テンプレートに対し、クエリのパラメーター化を強制することにより、アプリケーションを変更しないで改善することもできます。