1
私は、誤った見積もりのため、より速いクエリプランよりも遅いクエリプランが選択されている状況があります。しかし、間違った見積もりがどこから来ているのか分かりません。下に示すのは、インデックスシークの見積もりコスト123のために選択されていないより速いプランです。実際には、実際の金額と見積もられた金額の差異から見ると、コストはそれほど高くありません。私の理解では、実行の回数はネストされたループの上端からの行の数によって決まります。ご覧のとおり、見積もり行数は4878であり、実際にはかなり近いです。しかし、ボトム入力の推定実行回数は61110であり、これはオフです。 FWIW、フルスキャンですべてのテーブルの統計を更新し、1.22推定行が正しい（実行ごとに）。「実行回数の見積もり」が膨らんでいる
61110番号はどこから届いていますか、それを修正する方法はありますか？
クエリは次のようになります。私はまだ完全にはそれがこの問題の特定のインスタンスが判明として実行計画が、ここで私たちをすることができます見せているのか理解していないが、
SELECT
Top.Pk
FROM
Top
LEFT JOIN Bottom ON Bottom.Fk = Top.Pk
WHERE
Top.Date < GETUTCDATE()
AND Bottom.Fk IS NULL
私が言及したことを忘れてしまったトップテーブルは、重要な場合のインデックス付きビューです。 –
実際のクエリとテーブルの詳細を提供する必要があります。統計は、基数推定の1つの側面にすぎません。次のリストには、検索条件と結合条件が実際に表示されます。一般的な問題は、オプティマイザが実際のテーブルの内容と相関できない結合条件を持つことです。したがって、一致する行の数だけのテーブルサイズに基づいて推測値を取得します。もう1つの問題は、すべてのオプティマイザが知っているように、特定の一致で実際に60.000の結果の行が存在する可能性のある、非常に非同種の内容の表です。 –
この場合、GUIDに参加しています。トップテーブルのPKは、最下部のFKです。それがシークの唯一の述語です。均質性に関して、私はそれが統計の全ポイントだと思ったのですか？それにもかかわらず、推定行数は正しいです（特定の一致に60,000の結果行がない、1.22があります）。問題は、私が思った、実行の見積もり数です（スクリーンショットのネストされたループの説明によると）一番上の入力によって引き起こされます。 –