インテリジェント クエリ処理の概要

  • 6 分

SQL Server 2017 と 2019、および Azure SQL で、Microsoft では互換性レベル 140 と 150 に多くの新機能を導入しました。 これらの機能の多くは、ユーザー定義のスカラー値関数の使用や、テーブル変数の使用など、以前はアンチ パターンだったものを修正するためのものです。

これらの機能は、次のいくつかの機能ファミリに分類されます。

Screenshot of Intelligent Query Processing architecture.

インテリジェント クエリ処理には、最小限の実装作業で既存のワークロードのパフォーマンスを向上させる機能が含まれています。

ワークロードを自動的にインテリジェント クエリ処理の対象にするには、該当するデータベース互換性レベルを 150 に変更します。 例:

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 150;

アダプティブ クエリ処理

アダプティブ クエリ処理には、クエリの実行コンテキストに基づいて、クエリ処理をより動的に行うためのオプションが多数用意されています。 これらのオプションには、クエリの処理を強化する機能がいくつか含まれています。

  • アダプティブ結合 - データベース エンジンは、結合に含まれる行数に基づいて、ハッシュおよび入れ子にしたループの間の結合の選択を延期します。 アダプティブ結合は、現時点ではバッチ実行モードでのみ動作します。

  • インターリーブ実行 - 現在、この機能は、複数ステートメントのテーブル値関数 (MSTVF) をサポートしています。 SQL Server 2017 より前では、MSTVF は SQL Server のバージョンに応じて 1 行か 100 行のどちらかの固定行推定を使用していました。 関数がさらに多くの行を返す場合、この推定は最適ではないクエリ プランの原因となる可能性がありました。 インターリーブ実行では、プランの残りの部分がコンパイルされる前に、MSTVF から実際の行数が生成されます。

  • メモリ許可フィードバック - SQL Server により、統計からの行数推定に基づいて、クエリの初期プランでメモリ許可が生成されます。 重大なデータ スキューは、行数の過大または過少推定につながるおそれがあります。これは、メモリの過剰な許可を招いてコンカレンシーが低下したり、過少な許可を招いてクエリによってデータが tempdb にスピルされたりする原因になる場合があります。 メモリ許可フィードバックを使用すると、SQL Server ではこれらの条件を検出して、クエリに許可するメモリ量を減少または増加させ、スピルや割り当て超過を防ぐことができます。

これらの機能はすべて、互換性モード 150 では自動的に有効になっており、有効にするために変更を加える必要はありません。

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

MSTVF と同様に、SQL Server 実行プランのテーブル変数には、1 行の固定行数推定が収められています。 MSTVF と同様に、変数が予想よりもはるかに多くの行数を持つ場合、この固定推定はパフォーマンス低下の原因となっていました。 SQL Server 2019 では、テーブル変数が分析されて、実際の行数を持つようになりました。 遅延コンパイルは MSTVF のインターリーブ実行と本質的に似ていますが、実行プラン内で動的に実行されるのではなく、クエリの最初のコンパイル時に実行される点が異なります。

行ストアのバッチ モード

バッチ実行モードでは、行ごとではなく、バッチでデータを処理できます。 計算や集計に多大な CPU コストが発生するクエリの場合、この処理モデルから最大のメリットが得られます。 バッチ処理と列ストア インデックスを分離することにより、さらに多くのワークロードでバッチ モード処理からメリットを得ることができます。

ユーザー定義スカラー関数のインライン化

以前のバージョンの SQL Server では、いくつかの理由によりスカラー関数のパフォーマンスは不十分でした。 スカラー関数は反復的に実行され、実際には 1 行ずつ処理していました。 実行プランでの適切なコスト見積もりが行われず、クエリ プランでの並列処理も許可されていませんでした。 ユーザー定義関数のインライン化により、実行プランにおいて、これらの関数はユーザー定義関数の演算子の代わりに、スカラー サブクエリに変換されます。 この変換により、スカラー関数呼び出しが含まれるクエリのパフォーマンスが大幅に向上する可能性があります。

個別値の概数

データ ウェアハウスの一般的なクエリ パターンとして、注文やユーザーの個別のカウントを実行するというものがあります。 このクエリ パターンは、大規模なテーブルではコストが高くなる可能性があります。 個別値の概数処理では、行をグループ化することにより、個別のカウントをはるかに高速に収集できます。 この関数では、97% の信頼区間で 2% のエラー率が保証されています。