クエリ ストアの使用シナリオQuery Store Usage Scenarios

適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) はいAzure SQL データベースAzure SQL DatabaseYesAzure SQL データベースAzure SQL Database はいAzure SQL Managed InstanceAzure SQL Managed InstanceYesAzure SQL Managed InstanceAzure SQL Managed Instance はいAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse Analytics適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) はいAzure SQL データベースAzure SQL DatabaseYesAzure SQL データベースAzure SQL Database はいAzure SQL Managed InstanceAzure SQL Managed InstanceYesAzure SQL Managed InstanceAzure SQL Managed Instance はいAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse Analytics

クエリ ストアは、予測可能なワークロードのパフォーマンスの追跡と確保が重要である幅広いシナリオで使用できます。Query Store can be used in wide set of scenarios when tracking and ensuring predictable workload performance is critical. 考慮できるいくつかの例を次に示します。Here are some examples you can consider:

  • プランの選択による後退が発生しているクエリを特定して修正するPinpoint and fix queries with plan choice regressions
  • 最もリソース消費量の多いクエリを特定し調整するIdentify and tune top resource consuming queries
  • A/B テストA/B testing
  • 新しい SQL ServerSQL Server にアップグレードするときにパフォーマンスの安定性を維持するKeep performance stability during the upgrade to newer SQL ServerSQL Server
  • アドホックなワークロードを識別して改善するIdentify and improve ad hoc workloads

プランの選択による後退が発生しているクエリを特定して修正するPinpoint and fix queries with plan choice regressions

通常のクエリの実行中に、重要な入力が変わったためにクエリ オプティマイザーが別のプランを採用することを決定する場合があります (データ カーディナリティの変化やインデックスの作成、変更、破棄、統計の更新など)。選択される新しいプランの大部分は、前に使用されていたプランよりも優れているか、同程度のパフォーマンスを提供します。During its regular query execution, Query Optimizer may decide to choose a different plan because important inputs became different: data cardinality has changed, indexes have been created, altered, or dropped, statistics have been updated, etc. For the most part, the new plan is better, or about the same than the plan used previously. ただし、新しいプランでパフォーマンスが大幅に低下することがあります。この状況をプランの選択変更による後退と呼びます。However, there are cases when new plan is significantly worse - this situation is referred to as plan choice change regression. クエリ ストアが導入される前は、これは、識別して修正することが難しい問題でした。その理由は、SQL ServerSQL Server では、使用されていた実行プランをユーザーが調べるための組み込みのデータ ストアが提供されていなかったためです。Prior to Query Store, it was an issue difficult to identify and fix as SQL ServerSQL Server did not provide built-in data store, for users to look at for execution plans that were used over time.

クエリ ストアを使って、次に示す操作を短時間で実行できます。With the Query Store, you can quickly:

  • 特定の期間 (最後の 1 時間、1 日、1 週間など) にわたって実行メトリックが低下しているすべてのクエリを識別します。Identify all queries which execution metrics have been degraded, in the period of time of interest (last hour, day, week, etc.). 分析をスピードアップさせるために、SQL Server Management StudioSQL Server Management Studioで、 [後退したクエリ] を使用します。Use Regressed Queries in SQL Server Management StudioSQL Server Management Studio to speed up your analysis.

  • 後退したクエリの中から、複数のプランがあり、プランの選択が不適切だったためにパフォーマンスが低下しているクエリを簡単に見つけ出します。Among the regressed queries, it's easy to find those that had multiple plans and which degraded because of the bad plan choice. [Regressed Queries] (後退したクエリ) の [プランの概要] ウィンドウを使用して、後退したクエリのすべてのプランと一定期間のクエリのパフォーマンスを視覚化します。Use Plan Summary pane in Regressed Queries to visualize all plans for a regressed query and their query performance over time.

  • 前のプランのほうがパフォーマンスが高いことが証明された場合は、そのプランを履歴から強制的に実行します。Force the previous plan from the history, if it proved to be better. [低下したクエリ][プランの強制] ボタンを使って、選んだプランをクエリで強制的に実行します。Use Force Plan button in Regressed Queries to force selected plan for the query.

プランの概要を示すクエリ ストアのスクリーンショット。Screenshot of the Query Store showing a plan summary.

このシナリオの詳細な説明については、「Query Store:A flight data recorder for your database」 (クエリ ストア: データベースのためのフライト データ レコーダー) ブログを参照してください。For detailed description of the scenario refer to Query Store: A flight data recorder for your database blog.

最もリソース消費量の多いクエリを特定し調整するIdentify and tune top resource consuming queries

ワークロードで数千のクエリが生成される可能性がありますが、通常は少数のクエリのみがシステム リソースの大半を実際に使用しています。このため、そのような少数のクエリに注目する必要があります。Although your workload may generate thousands of queries, typically only a handful of them actually use the most of the system resources and therefore require your attention. ほとんどの場合、リソースを大量に消費しているクエリの中から、後退しているクエリか、調整を行うことで改善できるクエリを見つけることができます。Among top resource consuming queries, you will typically find queries that are either regressed or those that can be improved with additional tuning.

調査を開始する最も簡単な方法は、 Management StudioManagement Studio[Top Resource Consuming Queries] (上位リソース消費クエリ) を開くことです。The easiest way to start exploration is to open Top Resource Consuming Queries in Management StudioManagement Studio. ユーザー インターフェイスは、次の 3 つのウィンドウに分かれています。上位リソース消費クエリを表すヒストグラム (左側)、選択したクエリで使用されたプランの概要 (右側)、および選択したプランの視覚化されたクエリ プラン (下部)。User interface is separated into three panes: A histogram representing top resource consuming queries (left), a plan summary for selected query (right) and visual query plan for selected plan (bottom). 分析するクエリの数と関心のある期間を制御するには、 [構成] ボタンをクリックします。Click the Configure button to control how many queries you want to analyze and the time interval of interest. 異なるリソース消費ディメンション (期間、CPU、メモリ、IO、実行回数) とベースライン (平均、最小、最大、合計、標準偏差) も選択できます。Additionally, you can choose between different resource consumption dimensions (duration, CPU, memory, IO, number of executions) and the baseline (Average, Min, Max, Total, Standard Deviation).

リソース使用量が上位のクエリを特定して調整できることを示すクエリ ストアのスクリーンショット。Screenshot of the Query Store showing that you can identify and tune top resource consuming queries.

右側のプランの概要を見て実行履歴を分析し、別のプランとそれらのランタイム統計を確認します。Look at the plan summary on the right to analyze the execution history and learn about the different plans and their runtime statistics. 下部ウィンドウで、別のプランを調べるか、別のプランを並べて ([比較] ボタンを使用します) それらを視覚的に比較します。Use the bottom pane to examine the different plans or to compare them visually, rendered side by side (use the Compare button).

パフォーマンスが低下したクエリを特定する際に必要なアクションは、問題の性質によって異なります。When you identify a query with suboptimal performance, your action depends on the nature of the problem:

  1. 複数のプランを使用して実行されたクエリで、最後のプランのパフォーマンスが前のプランに比べて大幅に悪化している場合は、プラン強制実行メカニズムを使用して、今後の実行で SQL ServerSQL Server が最適のプランを使用することを保証できます。If the query was executed with multiple plans and the last plan is significantly worse than previous plan, you can use the plan forcing mechanism to ensure SQL ServerSQL Server will use the optimal plan for future executions

  2. オプティマイザーが、XML プランに不足しているインデックスの有無を指示しているかどうかを確認します。Check if the optimizer is suggesting any missing indexes in XML plan. 指示がある場合は、不足しているインデックスを作成し、インデックスの作成後にクエリ ストアを使用してクエリのパフォーマンスを評価します。If yes, create the missing index and use the Query Store to evaluate query performance after the index creation

  3. クエリで使用される基になるテーブルの統計が最新であることを確認します。Make sure that the statistics are up-to-date for the underlying tables used by the query.

  4. クエリで使用されるインデックスがデフラグされていることを確認します。Make sure that indexes used by the query are defragmented.

  5. 高コストのクエリの書き直しを検討します。Consider rewriting expensive query. たとえば、クエリのパラメーター化を利用して、動的 SQL の使用率を下げます。For example, take advantages of query parameterization and reduce usage of dynamic SQL. データを読み取るときに最適なロジックを実装します (アプリケーション側ではなく、データベース側でデータのフィルター処理を適用します)。Implement optimal logic when read the data (apply data filtering on database side, not on application side).

A/B テストA/B testing

クエリ ストアを使用して、予定しているアプリケーションの変更の導入前と導入後のワークロードのパフォーマンスを比較します。Use Query Store to compare workload performance before and after the application change you plan to introduce. 次の一覧は、クエリ ストアを使用して、環境またはアプリケーションの変更がワークロードのパフォーマンスに与える影響を評価できるさまざまな例を示しています。The following list contains several examples where you can use Query Store to assess impact of the environment or application change to the workload performance:

  • 新しいアプリケーションのバージョンのロールアウト。Rolling out new application version.

  • 新しいハードウェアのサーバーへの追加。Adding new hardware to the server.

  • 高コストのクエリによって参照されているテーブルでの欠落したインデックスの作成。Creating missing indexes on tables referenced by expensive queries.

  • 行レベルのセキュリティのためのセキュリティ ポリシーの適用。Applying filtering policy for row-level security. 詳細については、「Optimizing Row Level Security with Query Store」(クエリ ストアによる行レベルのセキュリティの最適化) を参照してください。For more information, see Optimizing Row Level Security with Query Store.

  • OLTP アプリケーションによって頻繁に更新されるテーブルへの一時的なシステム バージョン管理の追加。Adding temporal system-versioning to tables that are frequently modified by your OLTP applications.

どのシナリオでも、次のワークフローが適用されます。In any of these scenarios apply the following workflow:

  1. 予定している変更の前に、クエリ ストアでワークロードを実行して、パフォーマンスのベースラインを生成します。Run your workload with the Query Store before the planned change to generate performance baseline.

  2. 管理された時間中に、アプリケーションの変更を適用します。Apply application change at the controlled moment in time.

  3. 十分な時間をかけてワークロードを実行して、変更後のシステムのパフォーマンス イメージを生成します。Continue running the workload long enough to generate performance image of the system after the change

  4. #1 と #3 の結果を比較します。Compare results from #1 and #3.

    1. [Overall Database Consumption(全体的なデータベースの消費)] を開いて、データベース全体に対する影響を判断します。Open Overall Database Consumption to determine impact to the entire database.

    2. [リソースを消費するクエリの上位] を開いて (または Transact-SQLTransact-SQLを使用して独自の分析を実行して)、最も重要なクエリに対する変更の影響を分析します。Open Top Resource Consuming Queries (or run your own analysis using Transact-SQLTransact-SQL) to analyze impact of the change to the most important queries.

  5. 変更を維持するか、ロールバックを実行する (新しいパフォーマンスが容認できない場合) かを決定します。Decide whether to keep the change or perform roll back in case when new performance is unacceptable.

次の図は、不足しているインデックスを作成した場合のクエリ ストアの分析 (手順 4) を示しています。The following illustration shows Query Store analysis (step 4) in case of missing index creation. [プランの概要] ウィンドウにインデックスの作成による影響を受けたクエリのこのビューを取得するには、 [リソースを消費するクエリの上位] を開きます。Open Top Resource Consuming Queries / Plan summary pane to get this view for the query that should be impacted by the index creation:

不足しているインデックスの作成の場合の、クエリ ストアの分析 (手順 4) を示すスクリーンショット。Screenshot showing the Query Store analysis (step 4) in case of missing index creation.

さらに、インデックス作成の前と後のプランを並べて表示して、それらを比較できますAdditionally, you can compare plans before and after index creation by rendering them side by side. (ツールバーの赤い四角形でマークされている [選択したクエリのプランを、別々のウィンドウで比較します] ツールバー オプションを選択します)。("Compare the plans for the selected query in a separate window" toolbar option, which is marked with red square on the toolbar.)

クエリ ストアと [選択したクエリのプランを、別々のウィンドウで比較します] ツール バー オプションを示すスクリーンショット。Screenshot showing the Query Store and the Compare the plans for the selected query in a separate window toolbar option.

インデックス作成前のプラン (上段の plan_id = 1) にはインデックス不足ヒントがあるため、クラスター化インデックス スキャンがクエリの最も高コストの操作であることがわかります (赤色の四角形)。Plan before index creation (plan_id = 1, above) has missing index hint and you can inspect that Clustered Index Scan was the most expensive operator in the query (red rectangle).

不足しているインデックスの作成後のプラン (下段の plan_id = 15) にはインデックス シーク (非クラスター化) があり、それによってクエリの全体的なコストが減少し、クエリのパフォーマンスが向上しています (緑色の四角形)。Plan after missing index creation (plan_id = 15, below) now has Index Seek (Nonclustered) which reduces the overall cost of the query and improves it performance (green rectangle).

クエリのパフォーマンスが向上しているため、分析に基づいてこのインデックスを保持することができます。Based on analysis you would likely keep the index as query performance has been improved.

新しい SQL ServerSQL Server にアップグレードするときにパフォーマンスの安定性を維持するKeep performance stability during the upgrade to newer SQL ServerSQL Server

SQL Server 2014 (12.x)SQL Server 2014 (12.x)の前のバージョンでは、最新バージョンのプラットフォームへのアップグレード中にパフォーマンスが後退するというリスクがありました。Prior to SQL Server 2014 (12.x)SQL Server 2014 (12.x), users were exposed to the risk of performance regression during the upgrade to the latest platform version. それは、新しいビットがインストールされると、クエリ オプティマイザーの最新バージョンがすぐにアクティブになるためでした。The reason for that was the fact that latest version of Query Optimizer became active immediately once new bits are installed.

SQL Server 2014 (12.x)SQL Server 2014 (12.x) 以降では、すべてのクエリ オプティマイザーの変更は最新のデータベース互換性レベルと連携しているため、プランの変更は、アップグレードの時点ではなく、ユーザーが COMPATIBILITY_LEVEL を最新のものに変更した時点で発生します。Starting with SQL Server 2014 (12.x)SQL Server 2014 (12.x) all Query Optimizer changes are tied to the latest database compatibility level, so plans are not changed right at point of upgrade but rather when a user changes the COMPATIBILITY_LEVEL to the latest one. この機能とクエリ ストアの組み合わせによって、アップグレード プロセス中のクエリのパフォーマンスを高いレベルで制御できます。This capability, in combination with Query Store gives you a great level of control over the query performance in the upgrade process. 推奨されるアップグレードのワークフローを次の図に示します。Recommended upgrade workflow is shown in the following picture:

推奨されるアップグレード ワークフローを示す図。Diagram showing the recommended upgrade workflow.

  1. データベース互換性レベルを変更しないで、SQL ServerSQL Server をアップグレードします。Upgrade SQL ServerSQL Server without changing the database compatibility level. 最新のクエリ オプティマイザーの変更は公開されませんが、クエリ ストアなどの新しい SQL ServerSQL Server の機能は提供されます。It doesn't expose the latest Query Optimizer changes but still provides newer SQL ServerSQL Server features including Query Store.

  2. クエリ ストアを有効にします。Enable Query Store. このトピックについて詳しくは、「ワークロードに合わせてクエリ ストアを調整する」をご覧ください。For more information on this topic, see Keep Query Store adjusted to your workload.

  3. クエリ ストアがクエリとプランをキャプチャできるようにして、ソースおよび以前のデータベース互換性レベルでパフォーマンス ベースラインを確立します。Allow Query Store to capture queries and plans, and establishes a performance baseline with the source/previous database compatibility level. すべてのクエリをキャプチャし、安定したベースラインが取得されるまで、十分にこの手順を続けます。Stay at this step long enough to capture all plans and get a stable baseline. 運用ワークロードの通常のビジネス サイクルの期間でかまいません。This can be the duration of a usual business cycle for a production workload.

  4. 最新のデータベース互換性レベルに移動します。最新のクエリ オプティマイザーの変更にワークロードを公開し、必要に応じて新しいプランを作成できるようにします。Move to latest database compatibility level: get your workload exposed to the latest Query Optimizer changes and let it potentially create new plans.

  5. クエリ ストアを使って、分析と後退の修正を行います。大部分の新しいクエリ オプティマイザーの変更はより適切なプランを生成します。Use Query Store for analysis and regression fixes: for the most part, the new Query Optimizer changes should produce better plans. ただし、クエリ ストアでは、簡単な方法でプランの選択による後退を特定し、プラン強制実行メカニズムを使用してそれらを修正できます。However, Query Store will provide an easy way to identify plan choice regressions and fix them using a plan forcing mechanism. SQL Server 2017 (14.x)SQL Server 2017 (14.x) 以降、自動プラン修正機能を使用すると、この手順は自動になります。Starting with SQL Server 2017 (14.x)SQL Server 2017 (14.x), when using the Automatic Plan Correction feature, this step becomes automatic.

    a.a. 回帰がある場合は、クエリ ストアで、正常に機能していた前のプランを強制的に適用します。For cases where there are regressions, force the previously known good plan in the Query Store.

    b.b. クエリ プランの適用に失敗した場合、またはパフォーマンスが依然として十分ではない場合は、データベースの互換性レベルを前の設定に戻し、Microsoft カスタマー サポートにお問い合わせください。If there are query plans that fail to force, or if performance is still insufficient, consider reverting the database compatibility level to the prior setting, and then engaging Microsoft Customer Support.


SQL Server Management StudioSQL Server Management Studio データベースのアップグレード タスクを使用して、データベースの データベース互換レベルをアップグレードします。Use SQL Server Management StudioSQL Server Management Studio Upgrade Database task to upgrade the database compatibility level of the database. 詳細については、「クエリ調整アシスタントを使用したデータベースのアップグレード」を参照してください。See Upgrading Databases by using the Query Tuning Assistant for details.

アドホックなワークロードを識別して改善するIdentify and improve ad hoc workloads

一部のワークロードには、アプリケーション全体のパフォーマンス向上のために調整できる支配的なクエリがありません。Some workloads do not have dominant queries that you can tune to improve overall application performance. 通常、これらのワークロードは、それぞれがシステムリソースの一部を消費する、比較的多数の異なるクエリに分類されます。Those workloads are typically characterized with relatively large number of different queries each of them consuming portion of system resources. これらのクエリは非常にまれに実行される一意のクエリである (通常は 1 回のみ実行されます。このためアドホックという名前がついています) ため、それらのランタイム消費は重要ではありません。Being unique, those queries are executed very rarely (usually only once, thus name ad hoc), so their runtime consumption is not critical. 一方で、アプリケーションが常に新しいクエリを生成する場合、システム リソースのかなりの部分がクエリのコンパイルで消費され、これは最適な状況ではありません。On the other hand, given that application is generating net new queries all the time, significant portion of system resources is spent on query compilation, which is not optimal. このような状況はクエリ ストアにとって理想的ではなく、大量のクエリとプランが予約済みの領域に殺到した場合、クエリ ストアが非常に短時間で読み取り専用モードに至る可能性があることを意味します。This is not ideal situation for Query Store either given that large number of queries and plans flood the space you have reserved which means that Query Store will likely end up in the read-only mode very quickly. サイズ ベース クリーンアップ ポリシー がアクティブな場合 (クエリ ストアを常に稼働させるために 強くお勧めします )、バックグラウンド プロセスによってほぼ常にクエリ ストア構造がクリーンアップされますが、この動作もシステム リソースを大幅に消費します。If you activated Size Based Cleanup Policy (highly recommended to keep Query Store always up and running), then background process will be cleaning Query Store structures most of the time also taking significant system resources.

[リソースを消費するクエリの上位] ビューに、ワークロードのアドホックな性質の最初の兆候が表示されます。Top Resource Consuming Queries view gives you first indication of the ad hoc nature of your workload:

リソース消費量上位のクエリの多くが 1 回しか実行されないことを示す [リソースを消費するクエリの上位] ビューのスクリーンショット。Screenshot of the Top Resource Consuming Queries view showing that the majority of top resources consuming queries is only executed once.

[実行回数] メトリックを使用して、上位クエリがアドホックであるかどうかを分析します (クエリ ストアを QUERY_CAPTURE_MODE = ALLで実行する必要があります)。Use Execution Count metric to analyze whether your top queries are ad hoc (this requires you to run Query Store with QUERY_CAPTURE_MODE = ALL). 上の図から、 [リソースを消費するクエリの上位] の 90% が 1 回だけ実行されていることがわかります。From the diagram above, you can see that 90% of your Top Resource Consuming Queries are executed only once.

別の方法として、Transact-SQLTransact-SQL スクリプトを実行して、システム内のクエリ テキスト、クエリ、およびプランの合計数を取得し、query_hash と plan_hash を比較することで、それらの違いを判別できます。Alternatively, you can run Transact-SQLTransact-SQL script to get total number of query texts, queries, and plans in the system and determine how different they are by comparing the query_hash and plan_hash:

--Do cardinality analysis when suspect on ad hoc workloads
SELECT COUNT(*) AS CountQueryTextRows FROM sys.query_store_query_text;  
SELECT COUNT(*) AS CountQueryRows FROM sys.query_store_query;  
SELECT COUNT(DISTINCT query_hash) AS CountDifferentQueryRows FROM  sys.query_store_query;  
SELECT COUNT(*) AS CountPlanRows FROM sys.query_store_plan;  
SELECT COUNT(DISTINCT query_plan_hash) AS  CountDifferentPlanRows FROM  sys.query_store_plan;  

ワークロードにアドホック クエリがある場合に取得できる可能性がある結果を次に示します。This is one potential result you can get in case of workload with ad hoc queries:

ワークロードにアドホック クエリがある場合に取得できる可能性がある結果のスクリーンショット。Screenshot of the potential result you can get in case of workload with ad hoc queries.

クエリの結果は、クエリ ストアに大量のクエリとプランがあるにもかかわらず、それらの query_hash と query_plan_hash には実際は違いがないことを示しています。Query result shows that despite the large number of queries and plans in the Query Store their query_hash and query_plan_hash are actually not different. 一意のクエリ テキストと一意の query_hash の 1 を大きく上回る比率は、ワークロードがパラメーター化に適した候補であることの兆候です。これは、クエリ間の違いが、クエリ テキストの一部として提供されるリテラル定数 (パラメーター) のみであるためです。A ratio between unique query texts and unique query hashes, which is much bigger than 1, is an indication that workload is a good candidate for parameterization, as the only difference between the queries is literal constant (parameter) provided as part of the query text.

通常、この状況は、アプリケーションが (ストアド プロシージャまたはパラメーター化クエリを呼び出すのではなく) クエリを生成するか、クエリを既定で生成するオブジェクト リレーショナル マッピング フレームワークに依存している場合に発生します。Usually, this situation happens if your application generates queries (instead of invoking stored procedures or parameterized queries) or if it relies on object-relational mapping frameworks that generate queries by default.

アプリケーション コードを管理している場合は、データ アクセス レイヤーをストアド プロシージャまたはパラメーター化クエリを利用するように書き換えることを検討できます。If you are in control of the application code, you may consider rewriting of the data access layer to utilize stored procedures or parameterized queries. ただし、この状況は、データベース全体 (すべてのクエリ) または query_hash が同じ個別のクエリ テンプレートに対してクエリのパラメーター化を強制実行することで、アプリケーションの変更なしで大幅に改善することもできます。However, this situation can be also significantly improved without application changes by forcing query parameterization for the entire database (all queries) or for the individual query templates with the same query_hash.

個別のクエリ テンプレートを使用するアプローチでは、プラン ガイドを作成する必要があります。Approach with individual query templates requires plan guide creation:

--Apply plan guide for the selected query template 
DECLARE @stmt nvarchar(max);  
DECLARE @params nvarchar(max);  
EXEC sp_get_query_template   
    N'<your query text goes here>',  
    @stmt OUTPUT,   
    @params OUTPUT;  
EXEC sp_create_plan_guide   

プラン ガイドを使用するソリューションはより正確ですが、より多くの作業が必要です。Solution with plan guides is more precise but it requires more work.

すべてのクエリ (または多くのクエリ) が自動パラメーター化の候補である場合は、データベース全体の FORCED PARAMETERIZATION を変更するほうが適切な方法である可能性があります。If all your queries (or the majority of them) are candidates for auto-parameterization, then changing FORCED PARAMETERIZATION for the entire database may be a better option:

--Apply forced parameterization for entire database  


このトピックの詳細については、「強制パラメータ化使用のガイドライン」を参照してください。For more information on this topic, see Guidelines for Using Forced Parameterization.

これらの手順のいずれかを適用した後、 [Top Resource Consuming Queries] (上位リソース消費クエリ) に、別のワークロードの図が表示されます。After you apply any of these steps, Top Resource Consuming Queries will show you different picture of your workload.

ワークロードの異なる図を示す [リソースを消費するクエリの上位] ビューのスクリーンショット。Screenshot of the Top Resource Consuming Queries view showing a different picture of your workload.

アプリケーションで、自動パラメーター化の候補にならない大量の異なるクエリが生成される場合があります。In some cases, your application may generate lots of different queries which are not good candidates for auto-parameterization. この場合、システムで大量のクエリが発生しているが、一意のクエリと一意の query_hash の比率が 1 に近い可能性があります。In that case, you see large number of queries in the system but the ratio between unique queries and unique query_hash is likely close to 1.

このような場合は、アドホック ワークロードの最適化サーバー オプションを有効にして、再び実行される可能性がないクエリによるキャッシュ メモリの無駄使いを防ぐことができます。In that case, you may want to enable the Optimize for Ad hoc Workloads server option to prevent wasting cache memory on queries that won't likely be executed again. クエリ ストアにこれらのクエリがキャプチャされないようにするには、 QUERY_CAPTURE_MODEAUTOに設定します。To prevent capture of those queries in the Query Store, set QUERY_CAPTURE_MODE to AUTO.

EXEC sys.sp_configure N'show advanced options', N'1' RECONFIGURE WITH OVERRIDE
EXEC sys.sp_configure N'optimize for ad hoc workloads', N'1'

参照See Also

クエリのストアを使用した、パフォーマンスの監視 Monitoring Performance By Using the Query Store
クエリ ストアを使用する際の推奨事項 Best Practice with the Query Store
クエリ調整アシスタントを使用したデータベースのアップグレードUpgrading Databases by using the Query Tuning Assistant