クエリプランは何を伝えることができますか？

はじめに

SQLクエリは、結果を取得する方法ではなく、期待される結果を記述します。サーバーが結果を返すために実行する必要のある特定の手順のセットは、クエリ実行プランと呼ばれます。計画はオプティマイザによって作成されます。プランの選択は実行速度に影響し、クエリパフォーマンスの問題分析の最も重要な要素の1つになります。

実行プランは、ツリー構造の形で相互に関連するオペレーターとそのプロパティで構成されます。各オペレーターは、個別の論理操作または物理操作を担当します。一緒に、それらはクエリテキストで説明された結果を確実にします。ツリー内では、演算子はSQLServerのメモリ内のクラスオブジェクトによって表されます。サーバーユーザー（つまり、あなたと私）には、SQL Server Management Studio（SSMS）環境によってグラフィカルに表示される、特定のスキーマを使用してXML形式で生成された説明が表示されます。

多くのさまざまなプランオペレーターとさらに多くのプロパティがあります。その上、新しいものが時々出現します。この記事では、考えられるさまざまな演算子のすべてをあえて説明するわけではありません。代わりに、この主題で最も興味深い追加を共有し、いくつかの古いが有用な要素を思い出させたいと思います。

サーバーバージョン

クエリプランが正しい形式（XML）で提供されている場合でも、フォーラムでサーバーバージョンのリクエストを見つけることができる場合があります。代わりに、時間を節約し、実行プランをXMLとして開くことができます。そして、計画を説明する最初の要素は、Buildプロパティのサーバーバージョンを示します。

この方法では、サーバーエディションに関する完全な情報を取得することはできませんが、ほとんどの場合、私たちが何を扱っているかを理解するだけで十分です。

テーブルの行数

2番目によくある質問は、「テーブルにはどのくらいの行が含まれていますか？」です。この情報は、クエリプランから取得することもできます（サーバーバージョン2008から）。このためには、問題のテーブルのデータアクセス演算子（スキャンまたはシーク）を選択し、 TableCardinalityを確認する必要があります。財産。もう1つの興味深いプロパティ、推定行サイズがあります行サイズの指定と、テーブルまたはインデックスサイズの概算評価（テーブルが圧縮されていない場合）。

これはテーブル内の実際の行数ではなく、オブジェクト統計からのデータであることに注意してください。ただし、このデータは、クエリを作成するときにオプティマイザが行う決定の基礎になります。

コンテキスト

クエリプランは、それが構築された注目すべきSET設定を保存します。設定を表示するには、プラン内のルート要素を選択し、オプションの設定を展開する必要があります財産。たとえば、計画が ARITHABORTで作成されたかどうかを知ることができます。オプションが有効になっています（この設定が異なると、多くの場合、2つの異なる計画と状況が発生し、パラメーターのスニッフィングが不適切になります）。

CPUの数

オプティマイザーで使用可能なプロセッサーの数を取得できます。このためには、 OptimizerHardwareDependentPropertieを開く必要があります s-> EstimatedAvailableDegreeOfParallelism 同じルート要素のパラメータを2で乗算します。使用可能なプロセッサが1つだけの場合は、乗算する必要はありません。

2 * 2 =4、4つのCPUが使用可能です。実際、コンピューターには4コアのプロセッサーが搭載されており、サーバーでは4つのコアすべてを使用できます。この情報は、計画が生成されたマシンを検出するのに役立ちます。

カーディナリティ推定バージョン

SQL Server 2014以降、Cardinality Estimator（RU）のいくつかのバージョンが利用可能になりました。このメカニズムは、プランを選択するときにオプティマイザが行うほとんどの決定に影響します。 CardinalityEstimatorのバージョンはCardinalityEstimationModelVersionから取得できます。 ルート演算子のプロパティ。

0 – SQL Server <=2012
120 – SQL Server 2014
130 – SQL Server 2016
140 – SQL Server vNext

クエリの実行時間と待機時間

SQL Server 2016 SP1以降、実際のクエリプランには、実行時間とプロセッサ時間に関する情報が含まれています。このデータを取得するには、 QueryTimeStatsを展開する必要がありますルート要素のプロパティとCpuTimeの値を表示しますおよびElapsedTime 。実行時間の収集を有効にしたり、「クエリはどのくらいの時間実行されましたか」と尋ねたりする必要はありません。もう–この情報はすべて計画に含まれています。

2番目の注目すべき改善点は、クエリ実行中の最長待機時間のトップ10です。このためには、 WaitStatsを拡張する必要がありますルート要素のプロパティ。この追加により、クエリの実行が遅い理由をより正確に把握でき、診断が大幅に簡素化されます。

パラメータタイプ

パラメータリスト クエリで使用されるパラメータを一覧表示するプロパティは、ずっと前に計画に存在していました。ただし、SQL Server 2016 SP1以降、パラメータデータ型 プロパティがパラメータ定義に追加されました。このプロパティは、パラメータのデータ型を格納します。型変換の問題を理解するのに役立ちます。

読み取られた行数と読み取られる推定行数

実行プランには、2つの非常に重要なプロパティ、実際の行数と推定行数が含まれています。これらのプロパティには、データ読み取り演算子によって返される行数に関する情報が含まれていますが、実際に読み取った行数は含まれていません。読み取られた行数と読み取られる推定行数プロパティは、この質問に答え、サーバーが実際に読み取った、または読み取る予定の行数を取得できるようにします。 ActualRowsRead（SSMSで読み取られた行数）プロパティは、SQL Server 2012 SP3、2014 SP2、2016SP1から利用できます。 EstimatedRowsRead （SSMSで読み取られる推定行数）プロパティは、SQL Server2016SP1から利用できます。

IO統計とオペレーター実行時間

SQL Server 2016、2014 SP2で確立され、実際のクエリプランで使用できる非常に便利なプロパティがいくつかあります。これらは、IOメトリック（オペレーターがIOを持っている場合）–実際のIO統計、CPUおよび実行時間メトリック–実際の時間統計、およびメモリメトリック（2016 SP1以降、オペレーターがメモリを必要とする場合）です。

プロパティには、並列プランの場合にスレッドに分割できる次の新しいメトリックが含まれます。

ActualElapsedms
実際のCPUms
実際のスキャン
ActualLogicalReads
ActualPhysicalReads
ActualReadAheads
ActualLobLogicalReads
ActualLobPhysicalReads
ActualLobReadAheads
InputMemoryGrant
OutputMemoryGrant
UsedMemoryGrant

上記のリストからわかるように、特定のオペレーターの実行、消費されたIO、およびメモリーに関する包括的な情報を取得できます。 SSMSの最新バージョンでは、これらのメトリックはプロパティウィンドウに表示されます。古いバージョンのSSMSを使用している場合は、プランをXMLとして開くことでそれらを取得できます。私の意見では、現在、推定コストではなく、実際に経過したリソースによってパーセントを表示するためのすべてがあります（Connectで提案を作成しました。したがって、アイデアが気に入った場合は、投票してください）。

有効なトレースフラグに関する情報

SQL Serverのトレースフラグは、デフォルトのサーバー動作からいくつかの異なる動作への特別な「スイッチ」です。 SQL Server 2014SP2および2016SP1と同様に、有効なトレースフラグに関する情報は、特定の要素のTraceFlagsプロパティで利用できます。クエリ作成時に最大100個の同時に有効なフラグを含めることができます。

tempdbへのデータ流出に関する情報

たとえば、SortやHash Matchなどの一部のプラン演算子は、クエリの実行中にメモリを必要とします。ただし、メモリボリュームはコンパイル時に計算されます。さまざまな理由（想定される数または行の誤った評価など）により、メモリボリュームが誤って計算される可能性があります。実行に必要なメモリよりも少ないメモリが割り当てられている場合、サーバーはデータをtempdbにスピルする必要があります。クエリの実行が遅くなります。このような状況への注意はサーバー2012で導入されましたが、SQL Server 2012 SP3、2014 SP2、2016から、診断情報が拡張され、流出データと読み取りデータの量が含まれるようになりました。したがって、問題を評価して適切な対策を講じることができます。

結論

実行プランには多くの有用な情報が含まれ、実際のクエリプランにはさらに多くの情報が含まれ、SQLServerの最新バージョンの実際のクエリプランは有用な情報のほんの一部にすぎません。この記事は、クエリプランを分析する方法を誰かに教えることを目的としたものではありません。代わりに、新しいプロパティや古いが過小評価されているプロパティなど、最も興味深いプランプロパティを検討しました。次回、クエリのパフォーマンスを分析する必要があるときに、この記事がお役に立てば幸いです。

この記事は、著者の許可を得てCodingsightチームによって翻訳されました。

便利なツール：

dbForge Query Builder for SQL Server –ユーザーは、手動でコードを記述しなくても、直感的なビジュアルインターフェイスを介して複雑なSQLクエリをすばやく簡単に作成できます。