インテリジェントなクエリ処理の機能の詳細

[アーティクル]
01/08/2024

適用対象:SQL Server Azure SQL Database Azure SQL Managed Instance

この記事では、さまざまなインテリジェントクエリ処理 (IQP) 機能、リリースノート、および詳細について詳しく説明します。インテリジェントなクエリ処理 (QP) 機能ファミリには、最小限の労力で実装できる、既存のワークロードのパフォーマンスを広範に改善する機能が含まれています。

データベースに対して適用可能なデータベース互換性レベルを有効にすることにより、自動的にワークロードをインテリジェントなクエリ処理の対象にすることができます。これは Transact-SQL を使って設定できます。たとえば、データベースの互換性レベルを SQL Server 2022 (16.x) に設定するには、以下です。

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 160;

すべての IQP 機能は、各データベースの互換性モードに応じて、Azure SQL Managed Instance と Azure SQL Database で使用できます。新しいバージョンで導入された変更の詳細については、次を参照してください。

バッチモードアダプティブ結合

適用対象: SQL Server (SQL Server 2017 (14.x) 以降) および Azure SQL データベース

バッチモード適応型結合機能を使うと、最初の入力のスキャンが 終わる まで、ハッシュ結合方法または入れ子になったループ結合方法のどちらを選ぶかを、単一のキャッシュされたプランを使用して遅延することができます。アダプティブ結合演算子は、入れ子になったループプランに切り替えるタイミングを決定するために使われるしきい値を定義します。したがって、実行中により適切な結合方法に動的に切り替えることができます。

互換性レベルを変更せずにアダプティブ結合を無効にする方法など、詳細については、「アダプティブ結合について」を参照してください。

MSTVF のインターリーブ実行

適用対象: SQL Server (SQL Server 2017 (14.x) 以降) および Azure SQL データベース

複数ステートメントのテーブル値関数 (MSTVF) は、ユーザー定義関数の一種です。パラメーターを受け取り、複数の T-SQL ステートメントを実行し、テーブルを RETURN できます。

インターリーブ実行は、MSTVF に関する固定カーディナリティ推定によるワークロードのパフォーマンスの問題に役立ちます。インターリーブ実行では、関数に基づく実際の行数を使用して、より正確なダウンストリームクエリプランを決定します。

MSTVF の固定のカーディナリティの推定は、SQL Server 2014 (12.x) 以降のバージョンでは 100、それより前の SQL Server バージョンでは 1 となります。

インターリーブ実行は、単一クエリ実行の最適化フェーズと実行フェーズの間の一方向境界を変更し、修正されたカーディナリティ推定に基づいてプランが適応できるようにします。最適化中に、データベースエンジンが複数ステートメントテーブル値関数 (MSTVF) を使用するインターリーブ実行の候補を検出した場合、最適化を一時停止し、該当するサブツリーを実行し、正確なカーディナリティの推定をキャプチャし、ダウンストリームの演算に対する最適化を再開します。

次の図では、MSTVF からの固定カーディナリティ推定の影響を示す全体実行プランのサブセットであるライブクエリ統計出力を示します

実際の行フローと推定行数を比較できますプランの 3 つの注目すべき領域があります (フローは右から左)。

MSTVF テーブルスキャンの推定行数は 100 の固定です。ただし、この例では、この MSTVF テーブルスキャンを通過したのはライブクエリ統計が示すように 527,597 であるのに対し、実際の推定は 527597 of 100 であり、固定の推定に大きな非対称があります。
Nested Loops 操作では、結合の外側によって返されるものと推定されたのは 100 行だけです。 MSTVF によって実際に返される行数が多いと、そっくり異なる結合アルゴリズムにした方がよくなると思われます。
Hash Match 操作では、小さい警告シンボルに注意してください。これはここではディスクへの書き込みを示します。

前のプランと、インターリーブ実行を有効にして生成された実際のプランを比較します。

MSTVF テーブルスキャンに正確なカーディナリティ推定が反映されるようになったことに注意してください。また、このテーブルスキャンと他の操作の順序の変更に注意してください。
結合アルゴリズムに関しては、Nested Loop 操作から Hash Match 操作に切り替えました。これは、多くの行が関係する場合に、より適しています。
また、MSTVF テーブルスキャンからフローする実際の行数に基づいて多くのメモリを許可しているので、ディスク書き込み警告は表示されなくなっています。

インターリーブ実行に適したステートメント

インターリーブ実行内のステートメントを参照する MSTVF は、現在は読み取り専用でなければならず、データ変更操作の一部であってはなりません。また、MSTVF は、ランタイム定数を使用していない場合は、インターリーブ実行には適しません。

インターリーブ実行の利点

一般に、推定行数と実際の行数の非対称が大きいほど、ダウンストリームプラン操作の数との組み合わせで、パフォーマンスへの影響が大きくなります。

一般に、インターリーブ実行は次の場合にクエリに対して利点があります。

中間結果セット (この例では MSTVF) で推定行数と実際の行数の非対称が大きい。
かつ、全体的なクエリが中間結果のサイズの変化による影響を受けやすい。これは通常、クエリプランのそのサブツリーの上に複雑なツリーが存在する場合に発生します。 MSTVF のシンプルな SELECT * では、インターリーブ実行によるメリットはありません。

インターリーブ実行のオーバーヘッド

オーバーヘッドは最小限か、ありません。 MSTVF はインターリーブ実行導入前に既に具現化されていましたが、違いは、今では最適化を延期でき、具現化された行セットのカーディナリティの推定を使用できることです。変更に影響を与える他のプランと同様に、一部のプランでは、サブツリーのカーディナリティがよくなることで、クエリ全体が悪いプランになることがあります。軽減策は、互換性レベルを元に戻すか、またはクエリストアを使ってプランの非機能低下バージョンを強制します。

インターリーブ実行と連続実行

インターリーブ実行プランがキャッシュされると、最初の実行の推定を修正されたプランが、インターリーブ実行を再インスタンス化することなく連続する実行に使われます。

インターリーブ実行アクティビティの追跡

実際のクエリ実行プランで使用法属性を確認できます。

実行プラン属性	説明
ContainsInterleavedExecutionCandidates	QueryPlan ノードに適用します。 true の場合、プランにインターリーブ実行候補が含まれることを意味します。
IsInterleavedExecuted	TVF ノードの RelOp 以下にある RuntimeInformation 要素の属性。 true の場合、操作がインターリーブ実行操作の一部としてマテリアル化されたことを意味します。

次の拡張イベントを使って、インターリーブ実行の発生を追跡することもできます。

xEvent	説明
`interleaved_exec_status`	このイベントは、インターリーブ実行が発生すると発生します。
`interleaved_exec_stats_update`	このイベントは、インターリーブ実行によって更新されたカーディナリティの推定を記述します。
`Interleaved_exec_disabled_reason`	このイベントは、インターリーブ実行の候補を含むクエリが実際にはインターリーブ実行されなかったときに発生します。

インターリーブ実行が MSTVF カーディナリティ推定を修正できるようにするには、クエリを実行する必要があります。ただし、ContainsInterleavedExecutionCandidates showplan 属性によるインターリーブ実行候補がある場合は、推定実行プランがまだ表示されます。

インターリーブ実行のキャッシュ

プランがキャッシュからクリアまたは消去された場合、クエリ実行時に、インターリーブ実行を使う新しいコンパイルが行われます。 OPTION (RECOMPILE) を使うステートメントは、インターリーブ実行を使う新しいプランを作成し、それをキャッシュしません。

インターリーブ実行とクエリストアの相互運用性

インターリーブ実行を使うプランは強制的に実行できます。プランは、最初の実行に基づいてカーディナリティの推定を修正されたバージョンです。

互換性レベルを変更することなく、インターリーブ実行を無効にする

インターリーブ実行は、データベースの互換性レベル 140 以上を維持しながら、データベースまたはステートメント範囲で無効にできます。データベースを発生源とするすべてのクエリ実行に対してインターリーブ実行を無効にするには、該当するデータベースとの関連で次を実行します。

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = OFF;

有効になっているとき、この設定は sys.database_scoped_configurations で有効として表示されます。データベースを発生源とするすべてのクエリ実行に対してインターリーブ実行を再有効化するには、該当するデータベースとの関連で次を実行します。

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;

USE HINT クエリヒントとして DISABLE_INTERLEAVED_EXECUTION_TVF を指定することで、特定のクエリでインターリーブ実行を無効にすることもできます。次に例を示します。

SELECT [fo].[Order Key], [fo].[Quantity], [foo].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession',
                            '1-01-2013',
                            '10-15-2014') AS [foo] ON [fo].[Order Key] = [foo].[Order Key]
                            AND [fo].[City Key] = [foo].[City Key]
                            AND [fo].[Customer Key] = [foo].[Customer Key]
                            AND [fo].[Stock Item Key] = [foo].[Stock Item Key]
                            AND [fo].[Order Date Key] = [foo].[Order Date Key]
                            AND [fo].[Picked Date Key] = [foo].[Picked Date Key]
                            AND [fo].[Salesperson Key] = [foo].[Salesperson Key]
                            AND [fo].[Picker Key] = [foo].[Picker Key]
OPTION (USE HINT('DISABLE_INTERLEAVED_EXECUTION_TVF'));

USE HINT クエリヒントは、データベーススコープ構成またはトレースフラグ設定に優先します。

スカラー UDF のインライン化

適用対象: SQL Server (SQL Server 2019 (15.x) 以降) および Azure SQL データベース

スカラー UDF のインライン化によって、スカラー UDF は関係式に自動的に変換されます。これらは呼び出し元の SQL クエリに埋め込まれます。この変換により、スカラー UDF を利用するワークロードのパフォーマンスが向上します。スカラー UDF のインライン化によって、UDF 内の操作をコストベースで簡単に最適化できるようになります。その結果、非効率的で反復的な直列の実行プランではなく、効率的でセット指向の並列処理になります。この機能は、データベース互換レベル 150 以上では既定で有効です。

詳細については、「スカラー UDF のインライン化」を参照してください。

テーブル変数の遅延コンパイル

適用対象: SQL Server (SQL Server 2019 (15.x) 以降) および Azure SQL データベース

テーブル変数の遅延コンパイルを使用すると、テーブル変数を参照するクエリのプランの品質および全体的なパフォーマンスが向上します。最適化と最初のプランのコンパイルの実行中に、この機能は実際のテーブル変数の行数に基づくカーディナリティの推定を反映します。この正確な行数の情報は、ダウンストリームプラン操作を最適化するために使用されます。

テーブル変数の遅延コンパイルを使用すると、テーブル変数を参照するステートメントのコンパイルは、そのステートメントが最初に実際に実行されるまで遅延されます。この遅延コンパイルの動作は、一時テーブルの動作と同じです。この変更によって、元の 1 行の推定値ではなく、実際のカーディナリティを使用できるようになります。

テーブル変数の遅延コンパイルを有効にするには、クエリを実行する際に接続されるデータベースに対してデータベース互換レベル 150 以上を有効にします。

テーブル変数の遅延コンパイルを使用することで、テーブル変数のその他の特性が変更されることはありません。たとえば、この機能はテーブル変数に列統計を追加しません。

テーブル変数の遅延コンパイルによって再コンパイルの頻度が増加することはありません。最初のコンパイルを行った場所でシフトします。結果として得られるキャッシュされたプランは、最初の遅延コンパイルのテーブル変数の行数に基づいて生成されます。キャッシュされたプランは、連続するクエリによって再利用されます。プランが削除されるか、再コンパイルされるまで再利用されます。

最初のプランのコンパイルに使用される table 変数の行数で示される標準値は、固定行数の推定値とは異なる場合があります。異なる場合、ダウンストリーム操作が役立ちます。テーブル変数の行数が実行全体で大幅に変化する場合は、この機能を使用してもパフォーマンスが改善しない可能性があります。

互換性レベルを変更することなく、テーブル変数の遅延コンパイルを無効にする

table 変数の遅延コンパイルは、データベースの互換性レベル 150 以上を維持しながら、データベースまたはステートメント範囲で無効にします。データベースを発生源とするすべてのクエリ実行に対してテーブル変数の遅延コンパイルを無効にするには、該当するデータベースとの関連で次のサンプルを実行します。

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

データベースを発生源とするすべてのクエリ実行に対してテーブル変数の遅延コンパイルを再度有効にするには、該当するデータベースとの関連で次のサンプルを実行します。

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

DISABLE_DEFERRED_COMPILATION_TV を USE HINT クエリヒントとして割り当てることで、特定のクエリに対してテーブル変数の遅延コンパイル無効にすることもできます。次に例を示します。

DECLARE @LINEITEMS TABLE 
    (L_OrderKey INT NOT NULL,
     L_Quantity INT NOT NULL
    );

INSERT @LINEITEMS
SELECT L_OrderKey, L_Quantity
FROM dbo.lineitem
WHERE L_Quantity = 5;

SELECT O_OrderKey,
    O_CustKey,
    O_OrderStatus,
    L_QUANTITY
FROM    
    ORDERS,
    @LINEITEMS
WHERE    O_ORDERKEY    =    L_ORDERKEY
    AND O_OrderStatus = 'O'
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));

パラメーターセンシティビティプラン最適化

適用対象: SQL Server (SQL Server 2022 (16.x) 以降)

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

詳細については、PSP最適化の、「パラメーターに依存するプランの最適化」を参照してください。
パラメーター化とパラメーター機密度の詳細については、「パラメーターの感度」と「パラメーターと実行プランの再利用」を参照してください。

概数クエリ処理

概数クエリ処理は新しい機能ファミリです。絶対的な精度よりも応答性が重要となる場合に、大規模なデータセット全体が集計されます。たとえば、ダッシュボードに表示するために、100 億の行に対する COUNT(DISTINCT()) を計算する場合などです。この場合、重要なのは絶対的な精度ではなく、応答性です。

個別の概算数

適用対象: SQL Server (SQL Server 2019 (15.x) 以降) および Azure SQL データベース

新しい集計関数 APPROX_COUNT_DISTINCT は、グループ内の一意の非 null 値の概数を返します。

この機能は、互換性レベルに関係なく、SQL Server 2019 (15.x) 以降で使用できます。

詳細については、「APPROX_COUNT_DISTINCT (Transact-SQL)」をご覧ください。

近似パーセンタイル

適用対象: SQL Server (SQL Server 2022 (16.x) 以降)、Azure SQL Database

これらの集計関数は、近似パーセンタイル集計関数を使って迅速に意思決定できるよう、許容されるランクベースのエラー境界で大規模なデータセットのパーセンタイルをすばやく計算します。

詳細については、「 APPROX_PERCENTILE_DISC (Transact-SQL) 」および「APPROX_PERCENTILE_CONT (Transact-SQL)」を参照してください

行ストアでのバッチモード

適用対象: SQL Server (SQL Server 2019 (15.x) 以降) および Azure SQL データベース

行ストアのバッチモードでは、列ストアインデックスを要求せず、分析ワークロードをバッチモードで実行できます。この機能は、ディスク上のヒープと B ツリーインデックスに対するバッチモード実行とビットマップフィルターをサポートしています。行ストアのバッチモードでは、既存のすべてのバッチモード対応演算子のサポートが有効になります。

Note

SQL Server のドキュメントでは、一般にインデックスに関して B ツリーという用語が使用されます。行ストアインデックスで、SQL Server によって B+ ツリーが実装されます。これは、列ストアインデックスやメモリ内データストアには適用されません。詳細については、「SQL Server と Azure SQL のインデックスのアーキテクチャとデザインガイド」を参照してください。

バッチモード実行の概要

SQL Server 2012 (11.x)では、分析ワークロードを促進する新機能である列ストアインデックスが導入されました。 SQL Server の後続の各リリースでユースケースと、列ストアインデックスのパフォーマンスを向上させました。テーブルに列ストアインデックスを作成すると、分析ワークロードのパフォーマンスが向上します。ただし、関連しているが異なる 2 つのテクノロジセットがあります。

列ストア インデックスでは、分析クエリは必要な列のデータにのみアクセスできます。列ストア形式のページ圧縮は、従来の行ストア インデックスの圧縮よりもはるかに効果的でもあります。
バッチモード処理では、クエリ演算子によってデータがより効率的に処理されます。一度に 1 行ずつではなく、複数行がバッチ処理されます。他にも多くのスケーラビリティの向上がバッチモード処理に関連付けられています。バッチモードの詳細については、「実行モード」を参照してください。

2 セットの機能が連携して、入力/出力 (I/O) と CPU の使用率が向上します。

列ストアインデックスを使用すると、より多くのデータがメモリに格納されます。これにより、I/O ワークロードが減少します。
バッチモード処理では、CPU がより効率的に使用されます。

2 つのテクノロジは可能な限り相互活用されます。たとえば、バッチモード集計は、列ストアインデックススキャンの一部として評価できます。また、圧縮された列ストアデータも、バッチモード結合とバッチモード集計により、ランレングスエンコードを使用してはるかに効率的に処理されます。

しかし、この 2 つの機能は独立していることを理解しておくことが重要です。

列ストアインデックスを使用する行モードプランを利用できます。
行ストアインデックスのみを使用するバッチモードプランを利用できます。

通常、2 つの機能を一緒に使用すると、最適な結果が得られます。 SQL Server 2019 (15.x)のため、これまで SQL Server のクエリオプティマイザーは、列ストアインデックスのあるテーブルが少なくとも 1 つ関係するクエリに対してのみバッチモード処理を検討しました。

一部のアプリケーションには、列ストアインデックスが適していない可能性があります。列ストアインデックスではサポートされていない他の機能を使用するアプリケーションもあります。たとえば、インプレースの変更は列ストアの圧縮と互換性がありません。そのため、クラスター化列ストアインデックスがあるテーブルでは、トリガーはサポートされません。さらに重要なことに、列ストアインデックスによって DELETE および UPDATE ステートメントにオーバーヘッドが増えます。

一部のトランザクションと分析のハイブリッドワークロードでは、トランザクションのワークロードでのオーバーヘッドが列ストアインデックスを使用することから得られるメリットを上回ります。このようなシナリオでは、バッチモードの処理だけを採用することにより、CPU 使用率を向上させることができます。このため、行ストアでのバッチモード機能では、関連するインデックスの種類に関係なく、すべてのクエリにバッチモードが検討されます。

行ストアでバッチモードの恩恵を受ける可能性があるワークロード

次のワークロードは、行ストアでのバッチモードの恩恵を受ける可能性があります。

ワークロードの大部分が分析クエリで構成されています。通常、このようなクエリでは、数十万行以上を処理する結合や集計などの演算子を使用します。
ワークロードが CPU バウンドです。ボトルネックが I/O の場合は、可能であれば列ストアインデックスを検討することを引き続きお勧めします。
列ストアインデックスを作成すると、ワークロードのトランザクション部分に過剰なオーバーヘッドがかかります。または、列ストアインデックスの作成が実行不可能です。アプリケーションは列ストアインデックスでまだサポートされていない機能に依存しているためです。

Note

行ストアでのバッチモードは、CPU 使用量を減らすことでのみ支援できます。ボトルネックが I/O に関連し、データがまだキャッシュされていない場合 ("コールド" キャッシュ)、行ストアでのバッチモードではクエリ経過時間が向上しません。同様に、すべてのデータをキャッシュするための十分なメモリがマシンにない場合、パフォーマンスは向上しない可能性があります。

行ストアでのバッチモードによる変化

行ストアのバッチモードでは、互換性レベル 150 のデータベースが必要です。

クエリで列ストアインデックスのあるテーブルにアクセスしない場合でも、クエリプロセッサではヒューリスティックを使用して、バッチモードを検討するかどうかが決定されます。ヒューリスティックは以下のチェックから構成されます。

テーブルサイズ、使用される演算子、入力クエリの推定カーディナリティの初期チェック。
オプティマイザーによってクエリに対する新しい低コストのプランが検出されたときの追加のチェックポイント。これらの代替プランがバッチモードを大いに利用しない場合、オプティマイザーではバッチモードの代替手段の探索が停止されます。

行ストアでバッチモードが使用されている場合、実際の実行モードはクエリプランで [バッチモード] と表示されます。 scan 演算子では、ディスク上のヒープと B ツリーインデックスにバッチモードを使用します。このバッチモードスキャンでは、バッチモードのビットマップフィルターを評価できます。また、プラン内の他のバッチモード演算子も表示されることがあります。たとえば、ハッシュ結合、ハッシュベースの集計、並べ替え、ウィンドウ集計、フィルター、連結、Compute Scalar 演算子などです。

解説

クエリプランは常にバッチモードを使用するわけではありません。クエリオプティマイザーでは、クエリがバッチモードの恩恵を受けないと判断される場合があります。

クエリオプティマイザーの検索スペースは変化しています。そのため、行モードプランを取得する場合、それがより低い互換性レベルで取得するプランと同じではない可能性があります。また、バッチモードプランを取得する場合、それが列ストアインデックスを使用して取得したプランと同じではない可能性があります。

新しいバッチモード行ストアスキャンが原因で、プランは、列ストアインデックスと行ストアインデックスが混在するクエリに対して変化する可能性もあります。

現在、行ストアスキャンには、新しいバッチモードに対して制限事項があります。

インメモリ OLTP テーブル、またはディスク上のヒープと B ツリー以外のインデックスに対しては開始されません。
大規模なオブジェクト (LOB) 列がフェッチまたはフィルター処理された場合にも開始されません。この制限には、スパース列セットと XML 列が含まれます。

列ストアインデックスでもバッチモードが使用されないクエリがあります。たとえば、カーソルを含むクエリです。これと同様の例外は、行ストアのバッチモードにも適用されます。

行ストアにバッチモードを構成する

既定では BATCH_MODE_ON_ROWSTOREデータベーススコープの構成は ON です。

データベースの互換性レベルを変更せずに、行ストアのバッチモードを無効にすることができます。

-- Disabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = OFF;

-- Enabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = ON;

データベーススコープ構成を使用して行ストアのバッチモードを無効にすることができます。ただし、その場合でも ALLOW_BATCH_MODE クエリヒントを使用してクエリレベルで設定をオーバーライドできます。次の例では、データベーススコープ構成を使用して無効になっている行ストアでのバッチモードを有効にします。

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('ALLOW_BATCH_MODE'));

DISALLOW_BATCH_MODE クエリヒントを使用して、特定のクエリに対して行ストアでのバッチモードを無効にすることもできます。次の例を参照してください。

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('DISALLOW_BATCH_MODE'));

クエリ処理フィードバック機能

クエリ処理フィードバック機能は、インテリジェントクエリ処理機能ファミリの一部です。

クエリ処理フィードバックは、SQL Server、Azure SQL Database、および Azure SQL Managed Instance のクエリプロセッサがクエリの実行に関する履歴データを使用して、クエリのコンパイルおよび実行方法に対する 1 つ以上の変更からヘルプを受け取る可能性があるかどうかを判断するプロセスです。パフォーマンスデータはクエリストアに収集され、クエリの実行を改善するためのさまざまな提案が表示されます。成功した場合は、今後の使用のために、これらの変更をメモリやクエリストアのディスクに保持します。提案によって十分な改善が得られない場合、それらは破棄され、クエリはそのフィードバックなしで引き続き実行されます。

SQL Server のさまざまなリリース、または Azure SQL データベースや Azure SQL Managed Instance で使用できるクエリ処理フィードバック機能の詳細については、「SQL データベースでのインテリジェントなクエリ処理」または各フィードバック機能に関する次の記事を参照してください。

メモリ許可フィードバック

メモリ許可フィードバックは、SQL Server の過去のメジャーリリースサイクルで導入されました。

バッチモードメモリ許可フィードバック

バッチモードメモリ許可フィードバックの詳細については、バッチモードメモリ許可フィードバックを参照してください。

行モードメモリ許可フィードバック

行モードメモリ許可フィードバックの詳細については、「行モードメモリ許可フィードバック」を参照してください。

パーセンタイルと永続化モードのメモリ許可フィードバック

パーセンタイルと永続化モードのメモリ許可フィードバックの詳細については、「パーセンタイルと永続化モードのメモリ許可のフィードバック」を参照してください。

並列処理の次数 (DOP) のフィードバック

DOP フィードバックの詳細については、「並列処理の次数 (DOP) のフィードバック」を参照してください。

カーディナリティ推定 (CE) のフィードバック

CE フィードバックの詳細については、カーディナリティ推定 (CE) フィードバックを参照してください。

クエリストアでの最適化されたプラン強制

クエリストアでのプラン強制の最適化については、「クエリストアでのプラン強制の最適化」を参照してください。

インテリジェントなクエリ処理の機能の詳細

バッチ モード アダプティブ結合

MSTVF のインターリーブ実行

インターリーブ実行に適したステートメント

インターリーブ実行の利点

インターリーブ実行のオーバーヘッド

インターリーブ実行と連続実行

インターリーブ実行アクティビティの追跡

インターリーブ実行のキャッシュ

インターリーブ実行とクエリ ストアの相互運用性

互換性レベルを変更することなく、インターリーブ実行を無効にする

スカラー UDF のインライン化

テーブル変数の遅延コンパイル

互換性レベルを変更することなく、テーブル変数の遅延コンパイルを無効にする

パラメーター センシティビティ プラン最適化

概数クエリ処理

個別の概算数

近似パーセンタイル

行ストアでのバッチ モード

バッチ モード実行の概要

行ストアでバッチ モードの恩恵を受ける可能性があるワークロード

行ストアでのバッチ モードによる変化

解説

行ストアにバッチ モードを構成する

クエリ処理フィードバック機能

メモリ許可フィードバック

バッチ モード メモリ許可フィードバック

行モード メモリ許可フィードバック

パーセンタイルと永続化モードのメモリ許可フィードバック

並列処理の次数 (DOP) のフィードバック

カーディナリティ推定 (CE) のフィードバック

クエリ ストアでの最適化されたプラン強制

関連するコンテンツ

フィードバック

フィードバック

その他のリソース

バッチモードアダプティブ結合

インターリーブ実行とクエリストアの相互運用性

パラメーターセンシティビティプラン最適化

行ストアでのバッチモード

バッチモード実行の概要

行ストアでバッチモードの恩恵を受ける可能性があるワークロード

行ストアでのバッチモードによる変化

行ストアにバッチモードを構成する

バッチモードメモリ許可フィードバック

行モードメモリ許可フィードバック

クエリストアでの最適化されたプラン強制