SQL Server でウィンドウ集計関数によってこのような大量の論理読み取りが発生するのはなぜですか?

ウィンドウ集計関数の論理読み取りが高くなる理由

実行プランで共通の部分式スプールを利用すると、論理読み取りが大幅に増加する傾向があります大きなテーブル用。実行計画を実験して観察した結果、次の式が成り立つことが判明しました:

ワークテーブルの論理読み取り = 1 NumberOfRows 2 NumberOfGroups 4

しかし、この公式の根本的な理由は依然として不明です。この記事は、この論理読み取り計算の背後にある謎を解明することを目的としています。

ウィンドウ集計関数の実行について

プランの最初のセグメント反復子は、行にフラグを追加します。それぞれの新しいパーティションの開始を示します。その後、プライマリ セグメント スプールは一度に 1 行ずつ行を取得し、それらを tempdb 作業テーブルに挿入します。新しいグループ フラグを検出すると、スプールはネストされたループ演算子の上部入力に行を返します。

これにより、作業テーブルの行に対するストリームの集計がトリガーされ、平均が計算されます。次に、計算された平均が作業テーブルの行と結合され、次のグループに備えて作業テーブルが切り詰められます。セグメント スプールは、最後のグループを処理するためにダミー行を生成します。

ワークテーブルの論理読み取り計算

私たちの理解によれば、ワークテーブルはヒープ (またはインデックス スプール)計画に別途指定がある場合）。この例では、予想に反して、11 回の論理読み取りのみが必要です。この違いの説明は次のとおりです。

• ワークテーブルへの行の挿入はそれぞれ 1 つの論理読み取りを考慮し、結果として 3 つの論理読み取りが行われます。
• 平均の計算には 1 つの論理読み取りが含まれます。合計 4 つの読み取りが行われます。
• 平均列を含む行を返すには、4 つの論理演算が必要です
• ワークテーブルを切り詰めると、論理読み取りは発生しません。

これにより、論理読み取りの合計は 4 x 3 = 12 になり、論理読み取りをトリガーする 4 行目の挿入が省略されます。オリジナルでのみシナリオ。

結論

この式を理解するための鍵は、ワークテーブルと通常のスプール テーブルの論理読み取りカウント間の不一致にあります。ワークテーブルの場合、読み取られた各行は 1 回の論理読み取りとしてカウントされますが、スプール テーブルの場合は、ハッシュされた各ページがカウントされます。

式は観察された実行と一致しています。2 つのセカンダリ スプールが 2 回読み取られます (2 COUNT) ())、プライマリ スプールは、次のブログ エントリで説明されているように (COUNT(DISTINCT CustomerID) 1) 行を出力します。追加情報。追加の行は、最後のグループの終わりを示すために発行された追加の行によるものです。

以上がSQL Server でウィンドウ集計関数によってこのような大量の論理読み取りが発生するのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。