クラスター化インデックスのヒストグラムスキュー
問題
Entity Frameworkから生成されたクエリを最適化しようとしていますが、実行プランに非常に不正確な見積もりが表示されていることに気付きました。少し掘り下げた後、いくつかのクラスター化されたインデックスの統計オブジェクトが非常に歪んでいることに気付きました。以下は、実際の行順に並べられた、クエリの上位演算子の一部です。
（出典： imgh.us ）
[〜＃〜] edit [〜＃〜]：データベース名を編集しました。
上から3番目の演算子（私が選択したもの）はクラスター化されたインデックスシークであり、その特定のインデックスの統計オブジェクトを見ると、途方もない量のスキューがあります。
（出典： imgh.us ）
これには理由がありますか？ SQLServerがフルスキャンでこのヒストグラムに対して3つのステップしか生成しない理由について私は混乱しています。テーブルに225,000以上の行があるので、より狭い範囲でより多くのステップが表示されると思いますが、実際に表示されているのは、ほぼすべての行が1つのステップに含まれていることです。インデックスを再構築して統計を更新しても、これは再配布されません。
その特定のインデックスに加えて、他の多くのクラスター化されたインデックス統計にも同様の問題があり、同様に悪い推定値を提供しているようです。上記のリストの別の演算子は、WorkOrderテーブルのクラスター化されたインデックススキャンであり、これも比較的悪い見積もりを生成します。これは行の30％を選択するカーディナリティ推定器であるように見えますが、おそらくパラメータスニッフィング（または統計以外のもの）の問題です。
基本的に、私の質問は次のとおりです。
- クラスター化されたインデックス統計はどのように見えるべきですか？
- 上記の配布は期待されていますか？
- 予想される場合、これらの悪い見積もりを回避するにはどうすればよいですか？
- 予期しない場合、これらの悪い統計を修正するにはどうすればよいですか？
EDIT2：XMLプランは次のとおりです： https://www.brentozar.com/pastetheplan/?id=rJTjT4zze
あなたの統計は大丈夫です。
それはあなたが持っていることをあなたに伝えています
- 値1の正確に1つの行
- 値が213152の1行
- 値213151の1行
- > 1および<213,151である213,144個の個別の値（したがって、基本的に、5個が欠落しているものの間の213,149個の可能な整数値ごとに1つの行）