クエリのパフォーマンスに関して、データベース統計はどの程度役立ちますか?
SQL Server 2014 クエリでデータベース エンジンのチューニングを行ったところ、クエリ処理が 79% 改善される可能性があり、推奨事項は 5 つの統計と 1 つのインデックスを作成することでした。
パフォーマンスに関しては、この場合、1 つのインデックスと比較して、パーセンテージに関して、5 つの統計はクエリのパフォーマンスをどのように改善しますか?
クエリのパフォーマンスに関して、データベース統計はどの程度役立ちますか?
SQL Server 2014 クエリでデータベース エンジンのチューニングを行ったところ、クエリ処理が 79% 改善される可能性があり、推奨事項は 5 つの統計と 1 つのインデックスを作成することでした。
パフォーマンスに関しては、この場合、1 つのインデックスと比較して、パーセンテージに関して、5 つの統計はクエリのパフォーマンスをどのように改善しますか?
統計はクエリのパフォーマンスに不可欠です。それらがなければ、オプティマイザーは、データへの経路のどの順列が最も効率的かを推測するだけです。すべてのテーブルへのすべてのアクセスは、テーブル スキャンに勝るものはありません。
これらは非常に重要であるため、SQL Server はアドホック クエリのためにオンザフライで作成します。を実行するSELECT * FROM MyTable WHERE ThisColumn = 'SomeValue'
と、 に関する統計が作成されThisColumn
ます。テーブル内のデータが修正されると、統計は最終的に「古く」なります。この時点で、オプティマイザーはそれらを無視し、本当に悪い計画を作成し始める傾向があります。パフォーマンスが崖から落ちます。以前は数秒かかっていたクエリが数分で完了します。
これらの特定のテーブルに関するこれら 5 つの統計については、私にはわかりません。テストして見てください。ただし、無料のランチはありません。統計を作成および維持するには、CPU、メモリ、および IO が必要です。それらが多ければ多いほど、オーバーヘッドが大きくなります。インデックスによく似ています。
ここにそれをカバーする良い記事があります。
簡単に言えば、統計はこれらの列の値の傾向の要約を作成しますが、インデックスは実際にはデータ構造 (通常は B ツリー) を作成して、その列のすべての値のスキャンを回避します。
パフォーマンスに関しては、通常、すべてのパフォーマンスはインデックスによってもたらされ、統計はクエリ実行のサブステップ (実行計画) 中の失敗を回避するのに役立つだけです。