実際の行数は推定行数よりも多い

実際の行数が推定行数を超えるのはなぜですか？私はMeasurementDateTime列の統計を更新しても、インデックスを再構築してきたものの実際の行数は推定行数よりも多い

CONSTRAINT [PK_AIRQUALITYTS] PRIMARY KEY CLUSTERED 
(
[FeatureID] ASC, 
[ParameterID] ASC, 
[MeasurementDateTime] DESC 
)

：

表は以下のように定義クラスタ化された主キーを持っています。

質問：

なぜ行の推定数よりも大きい実際の行数？そして、それはどんなパフォーマンスヒットですか？
実際の行数を見積もり行数と同じにする必要がありますか？実際の行と見積もった行の数の変動が私たちを悩ますべきではありませんか？

出典

2016-10-31 user641812

統計情報の更新にはどのスクリプトを使用しましたか？ FULLSCANと一緒に使いましたか？ –

あなたの質問に答えがありますが、数字の1つは見積もりです。見積もりは統計的サンプリングに基づいており、統計は古くなる可能性がありますが、見積もりが出る唯一の理由ではありません。 UPDATE STATISTICS

を実験として使用した。 – Cato

答えて

1：このテーブルには、合計でいくつの行があるかによって決まります。これは、SQLが実行計画を作成する際に使用する操作を決定する方法です。 AFIKの場合、SQLクエリオプティマイザは、約1/3以上のテーブル/インデックスを取得する必要があると見積もる場合、SEEK操作でSCANを使用することを決定します[cardinality estimate question on SO]

したがって、特定の場合に。

Q2：一般的なルールは、パフォーマンスの問題があることがわかっているクエリのみを最適化しようとすることです。

出典

2016-10-31 09:54:17

30％...私はそれが2〜3％のようだと思います。 –

sqlmag.comのこの記事の便利な情報：[** The Tipping Point ** - SQL Serverのクエリオプティマイザによる決定方法の理解]（http://sqlmag.com/database-administration/tippingpoint） –

@TT 。、これもチェックしてください：http://stackoverflow.com/questions/4579358/at-what-cardinality-does-sql-server-switch-to-an-index-scan-vs-seek –

2つの主な理由：2に関して

を使用している日付

バート・キャッシュされた計画のうち

統計、これは多くの場合、順番的に起因する問題をスニッフィングパラメータに起因しています特定の種類のクエリに適用されます。

ワークロードが何であるかわからない - クエリまたはストアドプロシージャ。

古いプランを使用していて、それをフラッシュする方法はたくさんあります。それらはすべてGoogle上にあります。

出典

2016-10-31 10:24:57

実際の行数は推定行数よりも多い

答えて

関連する問題