推定実行計画を表示すると、CXPACKET、PAGELATCH_SH、およびLATCH_EX [ACCESS_METHODS_DATASET_PARENT]の待機が生成されます

にmax degree of parallelism設定し2、にcost threshold for parallelism設定した4 vCPU VMでMicrosoft SQL Server 2016 SP2-CU6（13.0.5292.0）を実行しています50。

朝、SELECT TOP 100クエリの推定実行プランを表示しようとすると、大量の待機が発生し、推定プランをレンダリングする操作に数分、多くの場合5〜7分の範囲で時間がかかります。繰り返しますが、これはクエリの実際の実行ではなく、推定実行プランを表示するプロセスです。

sp_WhoIsActivePAGEIOLATCH_SH待機またはLATCH_EX [ACCESS_METHODS_DATASET_PARENT]待機のいずれかが表示され、操作中にポールランダルのWaitingTasks.sqlスクリプトを実行すると、待機が表示されるCXPACKETワーカースレッドでPAGEIOLATCH_SH待機が表示されます。

*リソースの説明フィールド= exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

ワーカースレッドは、statsテーブル全体をメモリに格納しているように見えます（Paul Randalのクエリから表示されるこれらのページ番号および後続のページ番号は、statsテーブルのクラスタ化キーに戻ります）。プランが戻ってくるstatsと、さまざまなレコードが残っているだけでキャッシュからテーブルの大部分が失われた後でも（同様のクエリからのシーク操作のためにプルされたと仮定します）、基本的に1日の残りの時間は瞬時です。

クエリが実際にSCAN演算子を使用するプランで実行されている場合、この初期動作を期待しますが、上記のリンクされたプランに示されているように、SEEKオペレーターに到達するためだけに実行プランを評価するときにこれを行うのはなぜですか？ここでのパフォーマンスを向上させるために何ができますか（営業時間前にこのステートメントを実行してデータを適切にキャッシュする以外に）。一対のカバリングインデックスが有益であると考えていますが、実際に動作の変更を保証しますか？ここで、ストレージとメンテナンスウィンドウの制限内で作業する必要があります。クエリ自体はベンダーソリューションから生成されるため、この時点で他の提案（より良いインデックス付け以外）を歓迎します。

統計の更新をトリガーした実際の実行計画のリクエストが表示されます。これは午前中に起こると述べているので、関連するテーブルに多くの変更を行う夜間プロセスがあると思いますか？

したがって、SQL Serverは統計を使用して計画を作成し、変更のしきい値に達し、操作の一部として自動統計更新を実行します。

共有した推定プランのXMLには、今朝からの統計の更新日が近いことがわかります。

LastUpdate="2019-05-06T09:12:49.92"
LastUpdate="2019-05-06T09:12:58.3"
LastUpdate="2019-05-06T09:13:20.33"
LastUpdate="2019-05-06T09:13:09.67"
LastUpdate="2019-05-06T09:12:59.05"
LastUpdate="2019-05-06T09:12:39.56"

これらが非常に大きく、ビジーなテーブルである場合（サンプリングの割合に基づいているようです）、統計情報の更新に多くの馬力がかかっていることはそれほど驚くことではありません。

SSMSで長い計画時間を見ると、可能性の順に次のいずれかです。

1. クエリオプティマイザーは、統計を作成または更新する必要があると判断しました。
2. 推定されるプランのサイズは非常に大きく（たとえば、10 MBを超える）、SSMSを表示するのに時間がかかるだけです。
3. クエリのコンパイル自体は、十分なプランを探す際のCPU使用率のため、実際には長い時間がかかりました。
4. サーバーが極端に強要されています。たとえば、ゲートウェイが使用可能になるまで待たなければならない場合があります。
5. コンパイル時間が極端に長くなるさまざまなバグ。

あなたの状況に対する答えは、ほぼ確実にSQL Serverが統計を更新または作成していることです。いくつかの手がかりがあります：クエリプランのサイズが小さく、クエリプランが比較的単純で低コストであり、コンパイルCPUがコンパイル時間よりも大幅に低い：

新しい寄稿者のJosh Darnellは、XMLの統計の最終更新時刻についての良い手がかりも指摘しました。

SQL Server 2019では、クエリが統計の更新を待機しているときのために、新しい待機タイプWAIT_ON_SYNC_STATISTICS_REFRESHが導入されています。そのバージョンでこの問題を診断する方がはるかに簡単です。それまでは、間接的な手法に頼るだけで済みます。

回避策には、メンテナンス期間中に統計を更新するか、データベースのAuto Update Stats Asyncを有効にすることが含まれます。変更する前に、そのオプションの完全な影響を理解してください。クエリプランは、統計が更新された後ではなく、統計が更新される前に作成されます。いくつかのワークロードでは、大きな勝利になる可能性があります。他の人にとっては、善よりも害を及ぼすことがあります。