SQL Server 2008R2での統計の自動更新：行が多数挿入されているにもかかわらず、一部の統計が古くなっているのはなぜですか？
遅いクエリの調査中に、実行プランは非常に最適ではないように思われました（推定実行数が1である、900万回のシークの実行をネストしたループ）。実際に古くなっているいくつかの関連する統計を確認したので、統計を再構築し、パフォーマンスの問題が効果的に解決されました。
このデータベースでは、統計の自動更新が有効になっています（デフォルトでオン）。 20％+ 500行の変更（更新/挿入/削除）に基づく自動統計更新のしきい値があることを理解しています。このしきい値は、複数のインデックスで大幅に超えているようです。そのため、（A）自動更新に問題があるか、（B）オンラインで見つけた以上の更新方法があります。ドキュメンテーション。
統計を更新するようにスケジュールされたタスクを設定できることを感謝します。これは他の解決策が見つからない場合に採用するアプローチである可能性が高いですが、そのような大量の変更によってトリガーされない理由について混乱します一部の統計情報の自動更新-スケジュールされたタスクで更新する必要がある統計情報を判断するのに役立つ理由を理解する。
追加のメモ：
1）負荷テストによってデータが作成されているデータベースで問題が指摘されたため、大量のデータが短時間で追加されているため、自動更新が定期的に（たとえば、1日に1回）発生した場合ほとんどの場合、これにより、観察された動作の一部が説明される場合があります。また、負荷テストはデータベースに大きな負荷をかける傾向があるため、負荷が高いときにSQLが統計の更新を延期しているのでしょうか（その後、何らかの理由で統計が更新されていません）。
2）連続するINSERT、SELECT、およびDELETEステートメントを含むテストスクリプトでこの問題を再現しようとすると、問題は発生しませんでした。ここでの違いは、これらのステートメントはそれぞれSQLステートメントごとに多くの行に影響を与えるのかどうか疑問に思っていますが、負荷テストスクリプトは行を個別に挿入する傾向があります。
3）問題のDBは「単純」復旧モデルに設定されています。
いくつかの関連リンク：
私はまた、Microsoft Connect経由でこの問題を提起しました：
UPDATE 2011-06-30：
さらなる調査では、しきい値レベル（たとえば、500行+ 20％）を超えて古くなっている統計は、問題のクエリで使用されていない統計であるため、クエリが実行されると更新される可能性が高いと思いますそれらを必要とします。クエリによってareが使用される統計の場合、これらは定期的に更新されます。残りの問題は、比較的少数の挿入（たとえば、前述の900万個程度のシークで推定数が1だった場合のシーク）後に、これらの統計がクエリプランオプティマイザーに著しく誤解を与えることです。
この時点で私の問題は、問題は主キーの選択の不備に関連しているということです。キーはNEWID（）を使用して作成された一意の識別子であるため、これにより、特にSQLのデフォルトのフィルファクターとして、非常に断片化されたインデックスが非常に迅速に作成されますサーバーは100％です。私の直感は、行挿入数が比較的少ないと、どういうわけか統計が誤解を招く結果になるということです-統計を再計算するためのしきい値を下回ります。インデックスを途中で再構築せずに大量のデータを生成したので、これはおそらく問題ではありません。したがって、結果として非常に高いインデックスの断片化が原因で統計が不十分である可能性があります。 SQL Serverのメンテナンスサイクルを負荷テストに追加して、長期にわたる実際のシステムのパフォーマンスをよりよく理解する必要があると思います。
UPDATE 2012-01-10：
考慮すべきもう1つの要素。 SQL Server 2005に2つのトレースフラグが追加され（2008年にも引き続き存在するようです）、古い統計情報や誤解を招く統計情報の発生に関連する特定の欠点に対処します。問題のフラグは次のとおりです。
DBCC TRACEON(2389)
DBCC TRACEON(2390)
MSDN：Ian JoseのWebLog：昇順のキーと自動クイック修正された統計昇順の列の統計、Fabiano Amorim
これらのフラグが有害な影響を与える可能性があるので、これらのフラグを有効にすることを決定するときはもちろん、非常に注意する必要があります。
決定的な答えではないとしても、いくつかの情報
最近ブログに投稿されました
ホワイトペーパー もあります。 「SQL Server 2008での統計の維持」のセクションを参照してください。影響を受けると思われるいくつかの条件があります。例：
自動更新ロジックの1つの制限は、統計の列への変更は追跡しますが、述語の列への変更は追跡しないことです。フィルターされた統計の述部で使用される列に多くの変更がある場合は、手動更新を使用して変更に対応することを検討してください。
最後に、チェックするいくつかの設定もあります。DBレベルでOFFになっていて、インデックス/統計レベルでONを上書きした場合はどうなりますか？
HTH ...