インテリジェントなクエリ処理の機能の詳細
適用対象: 
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 2022 (16.x) Azure SQL データベース Azure SQL Managed Instance
パラメーター センシティビティ プラン (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
ドキュメントでは、一般的にインデックスに関して B ツリーという用語が使用されます。 行ストア インデックスで、データベース エンジンによって 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) フィードバックを参照してください。
クエリ ストアでの最適化されたプラン強制
クエリ ストアでのプラン強制の最適化については、 「クエリ ストアでのプラン強制の最適化」を参照してください。
関連するコンテンツ
- 結合 (SQL Server)
- 実行モード
- クエリ処理アーキテクチャ ガイド
- プラン表示の論理操作と物理操作のリファレンス
- ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)
- SQL Server 2017 の新機能
- SQL Server 2019 の新機能
- SQL Server 2022 の新機能
- インテリジェントなクエリ処理のデモ
- 定数のたたみ込みと式の評価
- GitHub でのインテリジェントなクエリ処理のデモ
- SQL Server データベース エンジンと Azure SQL Database のパフォーマンス センター
- クエリ ストアを使用したパフォーマンスの監視
- クエリ ストアを使用してワークロードを監視するためのベスト プラクティス