誤った推定行数
ストアドプロシージャで経験した問題を特定しようとしています。
ストアドプロシージャがselect句でUDFを使用している（おそらくそれが問題の原因である）と言わなければなりませんが、とにかく、そうでない場合でも、実行プランの一部を以下に示します。
ここで、ハッシュマッチの出力推定行と非クラスター化インデックスIX_Job_OperationIDのIndex_Seekの推定行の両方が完全に間違っています。
Fullscanオプションを使用しても、インデックスIX_Job_OperationIDに関連する統計を更新しようとしましたが、役に立ちませんでした。
UPDATE STATISTICS Job [IX_Job_OperationID] with fullscan
含まれているデータセットが提供されたパラメーターを指定すると、大幅に変更される可能性があるため、storedでrecompileオプションも使用しています。
誰かが私を正しい方向に向けて、統計が更新されたにもかかわらず、推定値が実際から遠い理由を理解できるようにできますか？
ここに実際のリンク 実行計画
この実行プランでは、合計で8,610,665の論理読み取りが発生しますが、何らかの方法で選択される他のより優れたプランは、約122,692
問題の説明に基づいて、UDFがカーディナリティ推定エラーの原因である可能性は低いです。テストしたい場合は、UDFをコメント化して、結合の推定値が変化するかどうかを確認してください。
統計情報がFULLSCANで更新されている場合でも、カーディナリティの推定エラーが発生する可能性があります。 SQL Serverによって作成されたヒストグラムは、オプティマイザが十分な計画を作成する方法でデータをモデル化しない場合があります。SQLServerは、結合されたデータと正確に一致するヒストグラムを持たない場合があります（内部テーブルまたは外部テーブル、あるいはその両方でフィルタリングできます）。推定を複雑にする複数の列で結合している場合があります。たとえば、MicrosoftはSQL Server 2014でリリースされた新しいCEを使用して、結合カーディナリティの見積もり計算の一部を変更しました。一部のテーブルには、レガシーCEの前提条件によく一致するデータがあり、一部のテーブルには、新しいCEの前提条件によく合うデータがあります。 CE。
最初の見積もりの問題（38999の見積もり行と701680の実際の行）では、提供した内容に基づいて、結合カーディナリティの計算についてのみ読むことをお勧めします。 Microsoftは、SQL Server 2014の新しいカーディナリティエスティメータ用の ホワイトペーパー をリリースしました。また、結合カーディナリティの内部についてかなり詳しく説明している ブログ投稿 も知っています。質問が書かれているので、良い答えを出すには原因が多すぎます。さらにガイダンスが必要な場合は post 実際の実行計画をご覧ください。
2番目の推定問題（1つの推定行と1546894の実際の行）の場合、推定行数は、結合の内部ループの1回の反復に対するものであることに注意してください。実際の行数は、結合のすべての反復でテーブルから返されるすべての行に対するものであるため、ネストされたループ結合では一致しないことがよくあります。あなたが見ているものは一般的であり、必ずしも問題の兆候ではありません。