web-dev-qa-db-ja.com

貧弱な推定をもたらす大きなテーブルのマルチカラム統計

かなり大きなテーブル（約2億行）があり、統計情報は_WITH FULLSCAN_を使用して最新ですが、ヒストグラム（200ステップに制限）が広すぎてオプティマイザがうまく機能しない可能性があります見積もり-言い換えると、もはや「選択的」では不十分なのでしょうか。この特定の顧客のデータベース/テーブルを使用すると、私のクエリプランの見積もりは、他の顧客と比較してかなりずれています。

私が関係している特定の統計は、テーブルのPK/CLUSTERED INDEXからのものです。これは、int（ParentId）およびsmalldatetime（TimeStamp）を含む複数列の統計です。

DBCC SHOW_STATISTICS('SomeTable', 'PK_SomeTable')を発行すると、次の出力が表示されます（ヒストグラムは省略されていますが、役立つ場合は投稿できます）。

_Name                    Updated              Rows       Rows Sampled    Steps   Density         Average key length  String Index    Filter Expression   Unfiltered Rows
PK_SomeTable            Jan 31 2014 10:59AM  181170887  181170887       200     2.022617E-05    8                   NO              NULL                181170887

All density     Average Length  Columns
0.0004892368    4               ParentId
5.519651E-09    8               ParentId, TimeStamp
_

私のクエリのほとんどは、これらの両方の列（ParentIdとTimeStamp）の組み合わせを使用して実行されます。小さいすべての密度の値は、このペアの選択性を示しています。明らかにPKであるためです。

（1）ヒストグラムにはParentId列のみが表示されているようです。ここで何か不足していますか？両方の列が考慮されていますか？

（2）200,000,000行/ 200ステップを取る場合、基本的に各ヒストグラムステップで1,000,000行が定義されています。これは、見積もりの​​問題を引き起こす可能性があるほど大きいようですよね？ tempdbへの流出のソートなどはどうですか？

（3）手動で作成された統計/フィルターされた統計は探求の道でしょうか？適用するフィルターのタイプを決定するにはどうすればよいですか？

sql-servert-sqlexecution-planstatistics
6
John Russell

そのような大きなテーブルでは、パーティション分割を検討します。残念ながら、特定の質問（1〜3）にはお答えできませんが、一般に（ネイティブパーティション化の代わりに）パーティションビューを使用する利点の1つは、パーティションビュー内の個々のテーブルが個別のオブジェクトと見なされ、それぞれ独自の統計を持つことです。 200ステップで。 ここ は、SQLSkillsのKimberly Trippが、パーティション化またはパーティション化されたビューだけでなく、2つを組み合わせることを検討する大きなテーブルに対して推奨する投稿です。

分割ビューがわからない場合は、複数のテーブルがあり、それぞれがデータの一部を保持しているビューと、テーブルを結合するUNION ALLを含むビューが上部にあるビューです。

興味がある場合に備えて、統計に関するキンバリーの別のブログを以下に示します。 他のいくつかの質問に答えるのに役立つはずです。

統計に関するコナーカニンガムの記事は次のとおりです。 Statistics、Damned Lies、and Statistics – What Statman？

5
Kenneth Fisher

20億行を超えるテーブルを持つクライアントがあり、統計を使用して適切な実行プランを生成できます。数億行しかないテーブルでも問題ありません。

テーブルの統計情報が本当に必要な場合は、フィルター処理された統計情報をテーブルに配置し、必要に応じて年または月でフィルター処理して、最適化されたデータをさらに取得できます。ただし、統計を手動で更新する必要があります。

現在持っている大きな統計のために、トレース フラグ2371 をオンにすることをお勧めします。このようにして、統計はより頻繁に更新されます。 async stats updates もオンにする必要があります。

この統計を使用したクエリで特定のパフォーマンスの問題が発生していますか？

1
mrdenny