統計を更新しているにもかかわらず、推定行が実際よりも高い
私は（匿名） クエリプラン を持っています
2つの列（Column2とColumn6）の実際の行数と推定行数の変動が大きいテーブル（Object8）があり、これはハッシュ一致演算子とソート演算子で確認できます。
Object8テーブルのすべての統計を更新しました（これらは数日古く、テーブルはほとんど変更されません）
他に何が問題でしょうか？
カーディナリティの推定値は単なる数値です。パフォーマンスの問題がない限り、問題はありません。質問で、クエリプランのいくつかのステップで実際の行数と推定行数に違いがあると述べました。それは確かに本当ですが、見積もりが実際の行数と正確に一致する重要なクエリプランが見つかることはほとんどありません。クエリパフォーマンスの問題の根本的な原因であることが判明していない限り、1,000行の違いに焦点を当てることはしません。
統計の更新を検討してみましょう。統計を更新した後でも、カーディナリティの推定が不正確になるのはなぜですか？多くの場合、統計は列のデータを完全に説明していません。これらはサンプリングされる可能性があり、一部のデータセットでは201ステップでは不十分である可能性があります。データに歪みがある場合、密度は適切なメトリックではありません。ヒストグラムは1つの列でしか使用できないため、完全な統計オブジェクトを使用しても、カーディナリティの推定に参加し、複数の列でフィルターを組み合わせるのは困難です。 SQL Serverには、列間の相関レベルに関する情報がない場合が多いため、推測する必要があります。
詳細については、Joe Sackによる SQL Server 2014 Cardinality Estimatorによるクエリプランの最適化 を参照することをお勧めします。これは、レガシーCEと新しいCEの間の多くの違いの1つについての引用です。
複数の結合条件
等価述語の結合を使用した結合の場合、レガシーCEは各等価述語の選択性を計算し、独立性を想定してそれらを結合します。対照的に、新しいCEは、結合列で計算された複数列の頻度に基づいて結合のカーディナリティを推定します。
CEは異なるモデルを使用します。 1つのモデルは、データまたは単一の結合にさえ、他のモデルよりも適している場合があります。この場合、統計とはほとんど関係がありません。統計を更新するだけでは、すべてのケースで適切な見積もりを得るには不十分です。
一方、支援が必要な特定のパフォーマンスがある場合は、より多くの情報を提供する必要があります。あなたが投稿したクエリプランには、驚くべきものは何もありません。クエリで発生するパフォーマンスの問題は何ですか？