ネストされたループの結合とパフォーマンススプール

ネストされたループの結合 、レイジーテーブルスプールを取得するチャンス 次のように増加します：

• 推定行数 結合の外部入力。
• 推定費用 内側の計画演算子の。

スプールのコストは、内部のオペレーターの実行を回避することで節約できることによって返済されます。内部反復が多くなり、内部コストが高くなると、節約が増加します。コストモデルでは、テーブルスプールの巻き戻し（キャッシュヒット）に比較的低いI / OおよびCPUコストの数値が割り当てられるため、これは特に当てはまります。パラメータがないということは内部データセットが静的であることを意味するため、ネストされたループ結合のテーブルスプールでは巻き戻しが発生するだけであることに注意してください。

スプールはデータをより密に保存する場合があります それを供給するオペレーターより。たとえば、ベーステーブルのクラスター化インデックスは、平均して1ページあたり100行を格納する場合があります。クエリに必要なのは、各ワイドクラスター化インデックス行からの単一の整数列値のみであるとします。スプール作業テーブルに整数値だけを格納するということは、1ページに800をはるかに超えるそのような行を格納できることを意味します。オプティマイザは、ワークテーブルページの数の見積もりを使用してテーブルスプールのコストを部分的に評価するため、これは重要です。 必要です。その他のコスト要因には、ループの反復の推定回数に対する、スプールの書き込みと読み取りに関連する行ごとのCPUコストが含まれます。

オプティマイザは、ネストされたループ結合の内側にレイジーテーブルスプールを追加するには、おそらく少し熱心すぎます。それでも、オプティマイザーの決定は、推定コストの観点からは常に理にかなっています。私は個人的にネストされたループの結合を高リスクと見なしています 、どちらかの結合入力カーディナリティの推定値が低すぎると、すぐに遅くなる可能性があるためです。

テーブルスプールmay コストを削減するのに役立ちますが、単純なネストされたループ結合の最悪の場合のパフォーマンスを完全に隠すことはできません。通常、インデックス付きの適用結合が望ましく、推定エラーに対してより耐性があります。オプティマイザーが必要に応じてハッシュまたはマージ結合を使用して実装できるクエリを作成することもお勧めします。

CREATE TABLE #T1 
(
    c1 integer NOT NULL
);
GO
INSERT #T1 (c1)
VALUES
    -- Duplicate outer rows
    (1), (2), (3), (4), (5), (6),
    (1), (2), (3), (4), (5), (6),
    (1), (2), (3), (4), (5), (6);
GO
SELECT * 
FROM #T1 AS T1
CROSS APPLY 
(
    SELECT COUNT_BIG(*) 
    FROM (SELECT T1.c1 UNION SELECT NULL) AS U
) AS CA (c);