パラメーターに依存するプランの最適化

適用対象: Sql Server 2022 (16.x) 以降のバージョン Azure SQL Database Azure SQL Managed Instance SQL データベース (Microsoft Fabric プレビュー)

パラメーターセンシティビティプラン (PSP) 最適化は、インテリジェントなクエリ処理機能ファミリの一部です。パラメーター化クエリに対してプランが 1 つキャッシュされているだけでは、受け取る可能性があるあらゆるパラメーター値に対して最適ではないシナリオに対処します。これは一様でないデータ分散のケースです。詳細については、「パラメーターの感度」と「パラメーターと実行プランの再利用」を参照してください。

この問題のシナリオの既存の回避策の詳細については、次を参照してください。

PSP 最適化を使用すると、パラメーター化された 1 つのステートメントに対して複数のアクティブなキャッシュされたプランが自動的に有効になります。キャッシュされた実行プランは、顧客が指定したランタイムパラメーター値に基づいて、さまざまなデータサイズに対応します。

パラメーター化について

SQL Server データベースエンジンでは、Transact-SQL (T-SQL) ステートメントでパラメーターまたはパラメーターマーカーを使用することで、新しい Transact-SQL ステートメントと既存のコンパイル済みの実行プランとを照合し、プランの再利用を促進するリレーショナルエンジンの機能が強化されています。詳細については、「簡易パラメーター化」を参照してください。

データベースのすべての SELECT、INSERT、UPDATE、および DELETE ステートメントをパラメーター化するように指定することで、いくつかの制約はありますが SQL Server の簡易パラメーター化の既定動作をオーバーライドすることもできます。詳細については、「強制パラメーター化」を参照してください。

PSP 最適化の実装

初回コンパイル時に、列統計ヒストグラムで一様でない分布が識別され、使用可能なすべての述語のうち、最も "リスクのある" パラメーター化された述語が最大 3 つまで評価されます。つまり、同じクエリ内の複数の述語が条件を満たしている場合、PSP 最適化では上位 3 つが選択されます。 PSP 機能では、プランキャッシュとクエリストア (クエリストアが有効な場合) が多すぎるプランの肥大化を回避するために、評価される述語の数が制限されます。

対象となるプランの場合、ディスパッチャー式と呼ばれる PSP 最適化ロジックを含むディスパッチャープランが初回コンパイルで生成されます。ディスパッチャープランは、カーディナリティ範囲の境界値の述語に基づいて、クエリバリアントにマップされます。

Terminology

ディスパッチャー表現

ランタイムパラメーター値に基づいて述語のカーディナリティを評価し、実行をさまざまなクエリバリアントにルーティングします。

ディスパッチャープラン

ディスパッチャー式を含むプランは、元のクエリ用にキャッシュされます。ディスパッチャープランは、基本的に、機能によって選択された述語のコレクションに、いくつかの追加の詳細を加えたものです。選択された述語ごとに、ディスパッチャー計画に含まれる詳細の一部は、高および低境界値です。これらの値は、パラメーター値を異なるバケットまたは範囲に分割するために使用されます。ディスパッチャープランには、境界値の計算に使用された統計も含まれています。

クエリバリアント

ディスパッチャープランは、ランタイムパラメーター値に基づいて述語のカーディナリティを評価する際に、それらの値を分類し、コンパイルして実行する個別の子クエリを生成します。これらの子クエリは、"クエリバリアント" と呼ばれます。クエリバリアントには、プランキャッシュとクエリストアに独自のプランがあります。

述語カーディナリティの範囲

実行時に、各述語のカーディナリティがランタイムパラメーター値に基づいて評価されます。ディスパッチャーは、コンパイル時にカーディナリティ値を 3 つの述語カーディナリティ範囲に分類します。たとえば、PSP 最適化機能では、次の図に示すように、低、中、高のカーディナリティ範囲を表す 3 つの範囲を作成できます。

つまり、パラメーター化されたクエリが最初にコンパイルされると、PSP 最適化機能によってディスパッチャープランと呼ばれるシェルプランが生成されます。ディスパッチャー式には、パラメーターのランタイム値に基づいてクエリバリアントにクエリを分類するロジックがあります。実際の実行が開始されると、ディスパッチャーは次の 2 つの手順を実行します。

ディスパッチャーは、指定されたパラメーターセットのディスパッチャー式を評価してカーディナリティ範囲を計算します。
ディスパッチャーは、これらの範囲を特定のクエリバリアントにマップし、バリアントをコンパイルして実行します。複数のクエリバリアントを持つことにより、PSP 最適化機能は、1 つのクエリに対して複数のプランを持つことを実現します。

カーディナリティ範囲の境界は、ディスパッチプランの ShowPlan XML 内で確認できます。

<Dispatcher>
  <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1000000">
    <StatisticsInfo Database="[PropertyMLS]" Schema="[dbo]" Table="[Property]" Statistics="[NCI_Property_AgentId]" ModificationCount="0" SamplingPercent="100" LastUpdate="2019-09-07T15:32:16.89" />
    <Predicate>
      <ScalarOperator ScalarString="[PropertyMLS].[dbo].[Property].[AgentId]=[@AgentId]">
        <Compare CompareOp="EQ">
          <ScalarOperator>
            <Identifier>
              <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[Property]" Column="AgentId" />
            </Identifier>
          </ScalarOperator>
          <ScalarOperator>
            <Identifier>
              <ColumnReference Column="@AgentId" />
            </Identifier>
          </ScalarOperator>
        </Compare>
      </ScalarOperator>
    </Predicate>
  </ParameterSensitivePredicate>
</Dispatcher>

PSP 最適化によって生成されたヒントは、クエリバリアントの ShowPlan XML の SQL ステートメントに追加されます。ヒントを直接使用することはできません。手動で追加した場合は解析 されません 。ヒントには、次の要素が含まれます。

オプション ( PLAN PER VALUE ( ObjectID = (int), QueryVariantID = (int), predicate_range ( [databaseName].[schemaName]。[tableName]。[columnName] = @paramName, lowBoundaryValue, highBoundaryValue ) )

ObjectID は、現在のステートメントが含まれているモジュール (つまり、ストアドプロシージャ、関数、トリガー) から取得されます。これは、ステートメントがモジュールから生成されたことを前提とします。ステートメントが動的 SQL またはアドホック SQL (つまり、 sp_executesql) の結果である場合、ObjectID 要素は等しくなります 0。
QueryVariantID は、PSP 最適化が選択したすべての述語の範囲の組み合わせとほぼ同じです。たとえば、クエリに PSP の対象となる 2 つの述語があり、各述語に 3 つの範囲がある場合、9 個のクエリバリアント範囲の番号は 1 から 9 になります。
述語範囲 は、ディスパッチャー式から生成される述語カーディナリティ範囲情報です。

また、クエリバリアントの ShowPlan XML 内 (Dispatcher 要素内)は以下です:

<Batch>
  <Statements>
    <StmtSimple StatementText="SELECT PropertyId,&#xD;&#xA;       AgentId,&#xD;&#xA;       MLSLinkId,&#xD;&#xA;       ListingPrice,&#xD;&#xA;       ZipCode,&#xD;&#xA;       Bedrooms,&#xD;&#xA;       Bathrooms&#xD;&#xA;FROM dbo.Property&#xD;&#xA;WHERE AgentId = @AgentId&#xD;&#xA;ORDER BY ListingPrice DESC option (PLAN PER VALUE(ObjectID = 613577224, QueryVariantID = 1, predicate_range([PropertyMLS].[dbo].[Property].[AgentId] = @AgentId, 100.0, 1000000.0)))" StatementId="1" StatementCompId="2" StatementType="SELECT" StatementSqlHandle="0x090085E4372DFC69BB9E7EBA421561DE8E1E0000000000000000000000000000000000000000000000000000" DatabaseContextSettingsId="1" ParentObjectId="0" StatementParameterizationType="1" RetrievedFromCache="false" StatementSubTreeCost="0.021738" StatementEstRows="3" SecurityPolicyApplied="false" StatementOptmLevel="FULL" QueryHash="0x476167A000F589CD" QueryPlanHash="0xDE982107B7C28AAE" StatementOptmEarlyAbortReason="GoodEnoughPlanFound" CardinalityEstimationModelVersion="160">
      <StatementSetOptions QUOTED_IDENTIFIER="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false" />

      <Dispatcher>
        <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1e+06">
          <StatisticsInfo LastUpdate="2019-09-07T15:32:16.89" ModificationCount="0" SamplingPercent="100" Statistics="[NCI_Property_AgentId]" Table="[Property]" Schema="[dbo]" Database="[PropertyMLS]" />
          <Predicate>
            <ScalarOperator ScalarString="[PropertyMLS].[dbo].[Property].[AgentId]=[@AgentId]">
              <Compare CompareOp="EQ">
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[Property]" Column="AgentId" />
                  </Identifier>
                </ScalarOperator>
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Column="@AgentId" />
                  </Identifier>
                </ScalarOperator>
              </Compare>
            </ScalarOperator>
          </Predicate>
        </ParameterSensitivePredicate>
      </Dispatcher>

    </StmtSimple>
  </Statements>
</Batch>

Remarks

SQL Server 2025 (17.x) Preview とデータベース互換性 170 以降、PSP の最適化には次の 4 つの機能強化が含まれています。
- DELETE、INSERT、MERGE、UPDATE などのデータ操作言語データ操作言語 (DML) ステートメントのサポート。
- tempdbのサポートが拡張されました。
- 同じテーブルに複数の有効な述語が存在するシナリオで考慮する追加の考慮事項。
- SQL Server 2025 (17.x) Preview およびデータベース互換性 query_with_parameter_sensitivity への変更が行われる前に、interesting_predicate_count、max_skewness、psp_optimization_supported、および query_type の各フィールドを含む拡張イベントに対して行われた変更内容。ただし、interesting_predicate_count、interesting_predicate_details、psp_optimization_supportedならびにquery_typeフィールドを含めます。詳細については、「拡張イベント」セクションを参照してください。
現在、PSP 最適化機能は等価述語でのみ機能します。
データ分散が大幅に変更された場合、ディスパッチャープランは自動的に再構築されます。クエリバリアントプランは、他の種類のクエリプランと同じように、必要に応じて個別に再コンパイルされ、既定の再コンパイルイベントが適用されます。再コンパイルの詳細については、「実行プランの再コンパイル」を参照してください。
sys.query_store_plan クエリストアシステムカタログビューは、通常のコンパイル済みプラン、ディスパッチャープラン、およびクエリバリアントプランを区別するように変更されました。新しいクエリストアシステムカタログビュー sys.query_store_query_variantには、元のパラメーター化されたクエリ (親クエリとも呼ばれます)、ディスパッチャープラン、およびその子クエリバリアント間の親子関係に関する情報が含まれています。
同じテーブルの一部である述語が複数ある場合、PSP 最適化では、基になる統計ヒストグラムに基づいて、データスキューが最も多い述語が選択されます。たとえば、SELECT * FROM table WHERE column1 = @predicate1 AND column2 = @predicate2で、両方のcolumn1 = @predicate1とcolumn2 = @predicate2が同じテーブルからのものであり、table1は、最も歪んだ述語のみが特徴によって評価されます。ただし、クエリ例に演算子 (例: UNION、ひとつ) が含まれている場合、PSP は複数の述語を評価します。たとえば、クエリに類似した特性がある場合、 SELECT * FROM table WHERE column1 = @predicate UNION SELECT * FROM table WHERE column1 = @predicatePSP は、このシナリオを 2 つの異なるテーブルであるかのように扱うため、このケースでは最大 2 つの述語を選択します。テーブルのエイリアスを使用して自己結合するクエリでも、同じ動作を確認できます。

クエリバリアントの ShowPlan XML は次の例のようになります。選択された両方の述語には、それぞれの情報が PLAN PER VALUE PSP-関連ヒントに追加されています。

<Batch>
  <Statements>
    <StmtSimple StatementText="SELECT  b.PropertyId, &#xD;&#xA;       AgentId, &#xD;&#xA;       MLSLinkId, &#xD;&#xA;       ListingPrice, &#xD;&#xA;       ZipCode, &#xD;&#xA;       Bedrooms, &#xD;&#xA;       Bathrooms &#xD;&#xA;FROM dbo.AgentProperty a join  PropertyDetails b on a.PropertyId = b.PropertyId&#xD;&#xA;WHERE AgentId = @AgentId and  Property_id=@Property_id&#xD;&#xA;UNION&#xD;&#xA;          SELECT  c.PropertyId, &#xD;&#xA;       AgentId, &#xD;&#xA;       MLSLinkId, &#xD;&#xA;       ListingPrice, &#xD;&#xA;       ZipCode, &#xD;&#xA;       Bedrooms, &#xD;&#xA;       Bathrooms &#xD;&#xA;FROM dbo.AgentProperty c join  PropertyDetails d on c.PropertyId = d.PropertyId&#xD;&#xA;WHERE AgentId = @AgentId and  Property_id=@Property_id option (PLAN PER VALUE(ObjectID = 981578535, QueryVariantID = 9, predicate_range([PropertyMLS].[dbo].[AgentProperty].[AgentId] = @AgentId, 100.0, 1000000.0),predicate_range([PropertyMLS].[dbo].[AgentProperty].[AgentId] = @AgentId, 100.0, 1000000.0)))" StatementId="1" StatementCompId="2" StatementType="SELECT" StatementSqlHandle="0x090051FBCD918F8DFD60D324887356B422D90000000000000000000000000000000000000000000000000000" DatabaseContextSettingsId="2" ParentObjectId="0" StatementParameterizationType="1" RetrievedFromCache="false" StatementSubTreeCost="29.2419" StatementEstRows="211837" SecurityPolicyApplied="false" StatementOptmLevel="FULL" QueryHash="0x6D2A4E407085C01E" QueryPlanHash="0x72101C0A0DD861AB" CardinalityEstimationModelVersion="160" BatchModeOnRowStoreUsed="true">
      <StatementSetOptions QUOTED_IDENTIFIER="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false" />
      <Dispatcher>
        <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1e+06">
          <StatisticsInfo LastUpdate="2022-08-11T20:42:35.02" ModificationCount="0" SamplingPercent="100" Statistics="[NCI_AgentProperty_AgentId]" Table="[AgentProperty]" Schema="[dbo]" Database="[PropertyMLS]" />
          <Predicate>
            <ScalarOperator ScalarString="[PropertyMLS].[dbo].[AgentProperty].[AgentId] as [a].[AgentId]=[@AgentId]">
              <Compare CompareOp="EQ">
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[AgentProperty]" Alias="[a]" Column="AgentId" />
                  </Identifier>
                </ScalarOperator>
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Column="@AgentId" />
                  </Identifier>
                </ScalarOperator>
              </Compare>
            </ScalarOperator>
          </Predicate>
        </ParameterSensitivePredicate>
        <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1e+06">
          <StatisticsInfo LastUpdate="2022-08-11T20:42:35.02" ModificationCount="0" SamplingPercent="100" Statistics="[NCI_AgentProperty_AgentId]" Table="[AgentProperty]" Schema="[dbo]" Database="[PropertyMLS]" />
          <Predicate>
            <ScalarOperator ScalarString="[PropertyMLS].[dbo].[AgentProperty].[AgentId] as [c].[AgentId]=[@AgentId]">
              <Compare CompareOp="EQ">
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[AgentProperty]" Alias="[c]" Column="AgentId" />
                  </Identifier>
                </ScalarOperator>
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Column="@AgentId" />
                  </Identifier>
                </ScalarOperator>
              </Compare>
            </ScalarOperator>
          </Predicate>
        </ParameterSensitivePredicate>
      </Dispatcher>
      <QueryPlan CachedPlanSize="160" CompileTime="17" CompileCPU="17" CompileMemory="1856" QueryVariantID="9">

PSP 最適化機能で使用される現在のスキューしきい値に影響を与えることができます。次の方法は 1 つ以上です。
- カーディナリティ推定 (CE) トレースフラグ、たとえばトレースフラグ 9481（グローバル、セッション、またはクエリレベル）
- 使用中の CE モデルを下げようとする、または複数の述語の独立に関して CE モデルが行う前提に影響を与える、データベーススコープの構成オプション。これは、複数列の統計が存在しない場合に特に役立ちます。これは、PSP 最適化がこれらの述語の立候補性を評価する能力に影響します。
- 詳細については、「SQL Server 2014 カーディナリティ推定機能を使用したクエリプランの最適化」ホワイトペーパーの「複数述語の相関の増加の前提条件」セクションを参照してください。新しい CE モデルでは、述語の結合と結合に対して、ある程度の相関関係とより低い独立性を想定しようとします。従来の CE モデルを使用すると、複数列結合シナリオでの述語の選択度を計算する方法に影響を与える可能性があります。このアクションは特定のシナリオでのみ考慮する必要があり、ほとんどのワークロードでレガシ CE モデルを使用することはおすすめしません。
PSP 最適化では、現在、各クエリバリアントが新しい準備済みステートメントとしてコンパイルおよび実行されています。これは、ディスパッチャープランがモジュール (ストアドプロシージャ、トリガー、関数、ビューなど) に基づいている場合に、クエリバリアントが親モジュールとの関連付けをobject_id理由の 1 つです。準備されたステートメントとして、object_idは、sys.objectsのオブジェクトに直接マップできるものではありませんが、基本的にはバッチテキストの内部ハッシュに基づく計算値です。詳細については、 DMV ドキュメントの sys.dm_exec_plan_attributesセクションを参照してください。

クエリバリアントプランはプランキャッシュオブジェクトストア (CACHESTORE_OBJCP) に配置され、ディスパッチャープランは SQL Plans キャッシュストア (CACHESTORE_SQLCP) に配置されます。ただし、PSP 機能は、クエリバリアントのobject_id 親を ObjectID 属性内に格納します。これは、親クエリが動的またはアドホック T-SQL ではなく、モジュールの一部である場合に PSP が ShowPlan XML に追加する PLAN PER VALUE ヒントの一部です。キャッシュされたプロシージャ、関数、トリガーの集計パフォーマンス統計は、それぞれの目的で引き続き使用できます。 sys.dm_exec_query_stats DMV のようなビューで見つかるようなより詳細な実行関連の統計には、クエリバリアントのデータがまだ含まれていますが、object_idテーブル内のクエリバリアントのsys.objects とオブジェクトの関連付けは現在一致しません。ただし、より詳細なランタイム統計が必要な各クエリバリアントに対して ShowPlan XML を追加で処理する必要はありません。クエリストアが有効になっている場合、クエリバリアントのランタイムと待機の統計情報は、追加の ShowPlan XML 解析手法なしでクエリストアから取得できます。
PSP クエリバリアントは新しい準備済みステートメントとして実行されるため、 object_id は、ShowPlan XML を細分化してテキストパターンマッチング手法 (つまり、追加の XQuery 処理) を適用することなく、プランキャッシュ関連 sys.dm_exec_* のさまざまな DMV に自動的に公開されることはありません。現在、適切な親オブジェクト ID を出力するのは、PSP 最適化ディスパッチャープランだけです。 object_idはクエリストアではプランキャッシュ階層が提供するよりも多くのリレーショナルモデルが許可されるため、クエリストア内で公開されます。詳細については、「クエリストアのシステムカタログビュー」sys.query_store_query_variantを参照してください。

Considerations

PSP 最適化を有効にするには、クエリを実行する際に接続されるデータベースのデータベース互換レベル 160 を有効にしてください。
PSP 最適化機能の追加の分析情報を得るには、クエリストア統合も有効にすることをおすすめします。それにはクエリストアを確実にオンにしてください。次の例では、 MyNewDatabaseと呼ばれる既存のデータベースのクエリストアを有効にします。

ALTER DATABASE [MyNewDatabase]
SET QUERY_STORE = ON (
    OPERATION_MODE = READ_WRITE,
    QUERY_CAPTURE_MODE = AUTO
);

Note

クエリストアは、SQL Server 2022 (16.x) 以降の時点で、新しく作成されたデータベースに対して既定で有効になっています。

データベースレベルで PSP 最適化を無効にするには、ALTER DATABASE SCOPED CONFIGURATION SET PARAMETER_SENSITIVE_PLAN_OPTIMIZATION = OFF データベーススコープ構成を使用します。
クエリレベルで PSP 最適化を無効にするには、DISABLE_PARAMETER_SENSITIVE_PLAN クエリヒントを使用します。
パラメータースニッフィングがトレースフラグ 4136、 PARAMETER_SNIFFING データベーススコープ構成、または USE HINT('DISABLE_PARAMETER_SNIFFING') クエリヒントによって無効になっている場合、関連付けられているワークロードと実行コンテキストに対して PSP 最適化が無効になります。詳細については、クエリヒントと ALTER DATABASE SCOPED CONFIGURATION に関するページを参照してください。
ディスパッチャーごとにプランキャッシュ内に保存される一意のプランバリアント数は、キャッシュの肥大化を回避するために制限されています。内部しきい値は文書化されていません。各 SQL バッチには複数のプランを作成する可能性があり、各クエリバリアントプランにはプランキャッシュに独立したエントリがあるため、許可されるプランエントリの既定の最大数に達する可能性があります。プランキャッシュの削除率が著しく高い場合、または CACHESTORE_OBJCP および CACHESTORE_SQLCPcache ストアのサイズが過剰な場合は、トレースフラグ 174 の適用を検討する必要があります。
クエリのためにクエリストア内に保存される一意のプランバリアント数は、max_plans_per_query 構成オプションによって制限されています。クエリバリアントには複数のプランを含めることができるので、クエリストア内のクエリごとに合計 200 個のプランを使用できます。この数値には、親クエリに属するすべてのディスパッチャーのすべてのクエリバリアントプランが含まれます。 max_plans_per_query クエリストアの構成オプションを増やすことを検討してください。
- 一意のプランの数が既定のクエリストア max_plans_per_query の制限を超える可能性がある例は、次の動作が発生するシナリオです。クエリ ID が 10 のクエリがあり、ディスパッチャープランが 2 つあり、各ディスパッチャープランにそれぞれ 20 個のクエリバリアント (合計で 40 個のクエリバリアント) があるとします。クエリ ID 10 のプランの合計数は、クエリバリアントと 2 つのディスパッチャープランの 40 プランです。また、親クエリ自体 (クエリ ID 10) に 5 つの標準 (ディスパッチャー以外) プランを含めることもできます。これにより、47 個のプラン (クエリバリアントから 40 個、ディスパッチャー 2 個、PSP 以外のプランが 5 つ) になります。さらに、各クエリバリアントに平均 5 つのプランがある場合、このシナリオでは、親クエリのクエリストアに 200 を超えるプランがある可能性があります。これは、この例の親クエリが参照している可能性があるデータセットのデータスキューの大きい値にも依存します。
特定のディスパッチャーへのクエリバリアントマッピングごとに、次の手順を実行します。
- query_plan_hash は一意です。この列は、sys.dm_exec_query_stats と、その他の動的管理ビューおよびカタログテーブルで使用できます。
- plan_handle は一意です。この列は、sys.dm_exec_query_stats、sys.dm_exec_sql_text、sys.dm_exec_cached_plans と、その他の動的管理ビューと関数およびカタログテーブルで使用できます。
- query_hash は、同じディスパッチャーにマップされる他のバリアントに共通であるため、入力パラメーター値のみが異なるクエリを合計したリソース使用率を特定できます。この列は、sys.dm_exec_query_stats、sys.query_store_query と、その他の動的管理ビューおよびカタログテーブルで使用できます。
- コンパイル時に特別な PSP 最適化識別子がクエリテキストに追加されるため、sql_handle は一意です。この列は、sys.dm_exec_query_stats、sys.dm_exec_sql_text、sys.dm_exec_cached_plans と、その他の動的管理ビューと関数およびカタログテーブルで使用できます。 last_compile_batch_sql_handle カタログテーブルの sys.query_store_query 列と同じハンドル情報をクエリストアで使用できます。
- query_id は、クエリストア内で一意です。この列は、sys.query_store_query と、その他のクエリストアカタログテーブルで使用できます。

クエリストアにおけるプラン強制

同じ sp_query_store_force_plan および sp_query_store_unforce_plan ストアドプロシージャを使用して、ディスパッチャーまたはバリアントプランを操作します。

バリアントが強制されている場合、親ディスパッチャーは強制されません。ディスパッチャーが強制されている場合、そのディスパッチャーのバリアントのみが使用に適していると見なされます。

他のディスパッチャーから以前に強制されたバリアントは非アクティブになりますが、ディスパッチャーが再度強制されるまで、"強制" 状態を保持します
非アクティブになっていたのと同じディスパッチャーで以前に強制されたバリアントが、再度強制されます

クエリストアのクエリヒントの動作

クエリストアヒントがクエリバリアント (子クエリ) に追加されると、ヒントは PSP 以外のクエリと同じ方法で適用されます。クエリストアの親クエリにもヒントが適用されている場合、クエリバリアントヒントの優先順位が高くなります。
クエリストアヒントが親クエリに追加され、子クエリ (クエリバリアント) に既存のクエリストアヒントがない場合、子クエリ (クエリバリアント) は親クエリからヒントを継承します。
クエリストアのクエリヒントが親クエリから削除された場合、子クエリ (クエリバリアント) にもヒントが削除されます。
RECOMPILEヒントが親クエリに追加された場合、PSP 機能はRECOMPILEヒントを持つクエリに対して動作しないため、既存のクエリバリアントプランがプランキャッシュから削除された後に、システムによって PSP 以外のプランが生成されます。
クエリストアヒントの結果は、拡張イベント query_store_hints_application_success と query_store_hints_application_failed イベントを使用して確認できます。 sys.query_store_query_hints テーブルには、適用されたクエリヒントに関する情報が含まれています。ヒントが親クエリにのみ適用されている場合、システムカタログには親クエリのヒント情報が含まれますが、子クエリは親クエリのヒントを継承しますが、子クエリのヒントは含まれません。

クエリヒントとプラン強制動作を含む PSP を次の表にまとめることができます。

クエリバリアントヒントまたはプラン	親にユーザーが適用したヒントがある	親にフィードバックが適用されたヒントがある	親が手動で計画を強制している	親に APC ¹ 強制プランがある
ユーザーによるヒント	クエリバリアントヒント	クエリバリアントヒント	クエリバリアントヒント	N/A
フィードバックによるヒント	クエリバリアントヒント	クエリバリアントヒント	クエリバリアントヒント	N/A
ユーザーによる強制的な計画	クエリバリアント強制プラン	クエリバリアント強制プラン	クエリバリアント強制プラン	クエリバリアント強制プラン
APC によって強制される計画	クエリバリアント強制プラン	クエリバリアント強制プラン	クエリバリアント強制プラン	クエリバリアント強制プラン
ヒントまたは強制プランなし	親ユーザーのヒント	ヒントなし	アクションなし	アクションなし

¹ 自動チューニング機能の自動プラン修正コンポーネント

拡張イベント

parameter_sensitive_plan_optimization_skipped_reason: パラメーターセンシティビティプラン機能がスキップされたときに発生します。このイベントを使用して、PSP の最適化がスキップされる理由を監視します。

次のクエリは、PSP がスキップされた可能性のあるすべての理由を示しています。
```
SELECT map_value
FROM sys.dm_xe_map_values
WHERE [name] = 'psp_skipped_reason_enum'
ORDER BY map_key;
```
parameter_sensitive_plan_optimization: クエリで PSP 最適化機能が使用されている場合に発生します。デバッグチャネルのみ。関心のあるフィールドには、次の項目があります。
- is_query_variant: ディスパッチャープラン (親) またはクエリバリアントプラン (子) のどちらであるかについて説明します
- predicate_count: PSP によって選択された述語の数
- query_variant_id: クエリバリアント ID が表示されます。値 0 は、オブジェクトがディスパッチャープラン (親) であることを意味します。
query_with_parameter_sensitivity: このイベントが発生すると、特徴が興味深いと見なした述語の数、興味深い述語に関する json 形式の詳細、および述語または述語に対して PSPO がサポートされているかどうかが表示されます。
query_with_parameter_sensitivity拡張イベントからの出力例

Field	Value
interesting_predicate_count	3
interesting_predicate_details	{"Predicates":[{"ColumnId":7,"TableId":1221579390,"Skewness":475038.75},{"ColumnId":7,"TableId":1221579390,"Skewness":475038.75},{"ColumnId":7,"TableId":1221579390,"Skewness":475038.75}]}
psp_optimization_supported	True
query_type	195

SQL Server 監査のビヘイビアー

PSP の最適化では、ディスパッチャープランステートメントと、ディスパッチャーに関連付けられているクエリバリアントの監査データが提供されます。 SQL Server 監査内の additional_information 列には、クエリバリアントに対する適切な T-SQL スタック情報も用意されています。 MyNewDatabase データベースを例として使用すると、このデータベースに T2 と呼ばれるテーブルが呼び出され、usp_test の名前がストアドプロシージャである場合、usp_test ストアドプロシージャの実行後に、監査ログに次のエントリが含まれる場合があります。

action_id	object_name	ステートメント	additional_information
AUSC			`<action_info xmlns="http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data"><session><![CDATA[Audit_Testing_Psp$A]]></session><action>event enabled</action><startup_type>manual</startup_type><object><![CDATA[audit_event]]></object></action_info>`
EX	usp_test	exec usp_test 300 (実行コマンド例: EXECによって300のテストを行う)
SL	T2	論理演算子や条件を使用して、dbo.t2 テーブルから ID に基づいてデータを選択します。SQL コード: select * from dbo.t2 where ID=@id	`<tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`
SL	T2	select * from dbo.t2 where ID=@id option (PLAN PER VALUE(ObjectID = 933578364, QueryVariantID = 1, predicate_range([MyNewDatabase].[dbo]。[T2]。[ID] = @id, 100.0, 100000.0))	`tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`
EX	usp_test	exec usp_test 60000
SL	T2	論理演算子や条件を使用して、dbo.t2 テーブルから ID に基づいてデータを選択します。SQL コード: select * from dbo.t2 where ID=@id	`<tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`
SL	T2	select * from dbo.t2 where ID=@id option (PLAN PER VALUE(ObjectID = 933578364, QueryVariantID = 3, predicate_range([TestDB_FOR_PSP].[dbo]。[T2]。[ID] = @id, 100.0, 100000.0))	`<tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`

既知の問題

Issue	検出した日	Status	解決した日
「特定の条件下で SQL Server 2022 (16.x) のクエリストアで発生するアクセス違反の例外」。 PSP 最適化クエリストア統合が有効になっていると、アクセス違反の例外が発生する可能性があります。詳細については、「パラメーターの機密性の高いプランの最適化」の「理由」の更新を参照してください。	2023 年 3 月	Resolved	2023 年 8 月(CU 7)
アクセス違反の例外は、SQL Server 2025 (17.x) プレビューの特定の条件下で読み取り可能なセカンダリレプリカで発生する可能性があります。読み取り可能なセカンダリ機能にクエリストアを使用するように構成されている読み取り可能なセカンダリデータベースで PSP 最適化が有効になっていると、アクセス違反が発生する可能性があります。	2025 年 9 月	回避策あり

回避策あり

特定の条件下で読み取り可能なセカンダリレプリカでアクセス違反の例外が発生する可能性がある

次の条件を満たすクエリでは、PSP クエリバリアントが親ディスパッチャーステートメントの永続化された状態を判断できない場合、アクセス違反が発生する可能性があります。

セカンダリレプリカで実行される
パラメータースニッフィングの影響を受けやすい
パラメーターに敏感なプラン (PSP) の最適化の対象として適格

回避策: 読み取り可能なセカンダリ機能にクエリストアを使用するようにオンボードされた各データベースのセカンダリで PSP を無効にします。特定のデータベースのコンテキスト内から、次の Transact-SQL ステートメントを発行します。

ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY
    SET PARAMETER_SENSITIVE_PLAN_OPTIMIZATION = OFF;

Resolved

「特定の条件下で SQL Server 2022 のクエリストアで発生するアクセス違反の例外」

Note

SQL Server 2022 (16.x) 累積的な更新プログラム 7 では、アクセス違反につながる可能性がある競合状態に関するいくつかの修正プログラムがリリースされました。

実行されたクエリの実行時統計が、クエリストアのメモリ内表現 (MEMORYCLERK_QUERYDISKSTORE_HASHMAP メモリ管理者) からディスク上のクエリストアのバージョンに永続化される際に発生するレースコンディションが原因で、この問題が発生しました。ランタイム統計情報として示されるランタイム統計は、DATA_FLUSH_INTERVAL_SECONDS ステートメントの SET QUERY_STORE オプションで定義された一定期間、メモリ内に保持されます。（既定値は15分です）。 Management Studio クエリストアダイアログボックスを使用して、 [データフラッシュ間隔 (分)] の値を入力できます。これは、内部的に秒に変換されます。メモリ不足が発生した場合、DATA_FLUSH_INTERVAL_SECONDS オプションで定義されている時間より前に、ランタイム統計がディスクにフラッシュされる可能性があります。クエリストアのクエリプランのクリーンアップに関連する追加のバックグラウンドスレッド (つまり、STALE_QUERY_THRESHOLD_DAYS および/または MAX_STORAGE_SIZE_MB クエリストアオプション) の場合、クエリストアからのクエリでは、クエリバリアントまたはその関連するディスパッチャーステートメントが予期せず参照解除される可能性があります。これにより、クエリストアへのクエリバリアントの挿入または削除操作中にアクセス違反が発生する可能性があります。

クエリストアの操作の詳細については、「クエリストアでデータを収集する方法」の「解説」セクションを参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-10-24