web-dev-qa-db-ja.com

ハッシュマッチスピル

ここでハッシュマッチの流出が起こっています。関連するテーブルでFULLSCANを使用して統計を更新したので、そうではありません。どんなポインタでも大歓迎です。

https://www.brentozar.com/pastetheplan/?id=Bkq1VjySm

SQL 2017 Enterpriseを使用しており、RAMは64GBです。

sql-serverperformanceoptimizationexecution-plansql-server-2017query-performance
2
sqlbanana

データのサイズを考えると、流出を完全に回避することは不可能かもしれませんが、クエリを改善するためにいくつかのことを行うことができます。

  1. 結合とwhere句の列がNCインデックスキーであることを確認してください
  2. 多くの列を選択していないので、それらを含めてインデックスをカバーすることを恐れないでください
  3. 行番号（RN）を計算すると、かなりのソートとスピルが発生します。これを修正するには、検討する価値があります 別のインデックス付け 。ここで使用している式、_DATEDIFF(day,s.COMPLETEDDATE,att.atd_date_は、...

NUTS

... _actual_day_difference_（_AND a.actual_day_difference BETWEEN -60 AND 90_）で得られる非SARGable述語は、行を〜5mmから〜400kまで削除します。クエリの初期段階で役立つ可能性があるかなりの削減。

問題は、DATEDIFF(day,s.COMPLETEDDATE,att.atd_date)の結果セット全体を生成してからフィルターで除外する必要があることです。 CTE、派生テーブル、またはインデックス付けされていないビューの内部にあるような固定計算は、それらを永続化しません。ここで私のQ＆Aを参照してください： 2つの日付列のSARGable WHERE句 。

enter image description here

attendとStudyの間に関係があるかどうかはわかりませんが、一時テーブルまたはインデックス付きビューを使用して式を具体化し、SARG可能にすることは価値があります。また、対応する日付データを保持するいずれかのテーブルへの追加の列の追加と入力を検討することもできます。

これにより、追加のインデックス作成オプションが開き、必要に応じてABSでDATEDIFFもマテリアライズすることができます。

これはSQL Server 2014用であるため、 非クラスター化列ストアインデックス を調査する価値があるかもしれません。これは、適切な行ストアインデックスを理解しようとする苦痛を軽減し、より大きなDWスタイルに適しています。このようなクエリ。

お役に立てれば！

4
Erik Darling