Google でauto_update_statisticsを見つけました。これを ON にすると、 Statisticsを更新する必要がなくなり、SQL Server がそれを実行します。
テーブルの挿入、更新(インデックス付き列の)、削除の結果、統計が更新されるのではないかと思っていましたか?はいの場合、トランザクションの待ち時間は発生しません。
Google でauto_update_statisticsを見つけました。これを ON にすると、 Statisticsを更新する必要がなくなり、SQL Server がそれを実行します。
テーブルの挿入、更新(インデックス付き列の)、削除の結果、統計が更新されるのではないかと思っていましたか?はいの場合、トランザクションの待ち時間は発生しません。
統計は、挿入/更新/削除操作自体では更新されません。これらの操作は、変更カウンターを更新するだけなので、SQL Server は変更がいくつあったか、および更新が必要かどうかを追跡できます。
統計を使用するクエリが実行されると、SQL Server は統計が古いかどうかをチェックし、必要に応じて統計を更新します。
この件に関する決定的な記事は、SQL Server 2008 のプラン キャッシュです(このフローチャートはそこから引用されています)。
前述のように、SQL Server は各列に加えられた変更の数を保持しています。プランがコンパイルされてからの変更の数が再コンパイルのしきい値 (RT) を超えた場合、プランは再コンパイルされ、統計が更新されます。RT は、テーブルの種類とサイズによって異なります。
RT は次のように計算されます。(n は、クエリ プランがコンパイルされるときのテーブルのカーディナリティを表します。)
永久テーブル
- n <= 500 の場合、RT = 500。
- n > 500 の場合、RT = 500 + 0.20 * n。一時テーブル
- n < 6 の場合、RT = 6。
- 6 <= n <= 500 の場合、RT = 500。
- n > 500 の場合、RT = 500 + 0.20 * n。
テーブル変数
- RT が存在しません。したがって、テーブル変数のカーディナリティが変更されるため、再コンパイルは行われません。
これらの再コンパイルのしきい値は、すべての状況に適しているわけではありません。たとえば、統計、行の見積もり、および昇順の日付列を参照し、トレースフラグ 2371を使用して動作を変更できます。
AUTO_UPDATE_STATISTICS_ASYNC
である場合OFF
、コンパイルを続行する前に、要求元の spid によって統計が更新されます。このオプションがオンの場合ON
、統計はバックグラウンドでシステム spid によって更新され、元のクエリはブロックされず、古い統計を使用し続けます。
FULLSCAN
統計を更新できるもう 1 つの方法は、インデックスを再構築すると、同時に統計も更新されることです。