回答:
私のアドバイス：
sp_updatestatsデータベース内のすべてのテーブルのすべての統計情報が更新されますが、ストアドプロシージャの再コンパイルも発生するため、慎重に時間を選択してください（つまりsp_updatestats、月末レポートがおそらく最適ではない直前）。インデックスメンテナンス/再構築の統計を実行する必要がある頻度は、データベースの負荷、特にデータが変更される頻度（つまりINSERT/ UPDATE/ DELETE）によって異なります。ショー全体（つまり、毎週のバッチプロセスのステージングテーブル）でデータを変更している場合は、おそらく統計を毎晩更新/インデックスを再編成する必要があります。データがかなり静的な場合は、週単位または2週間単位のスケジュールにすることができます。
ヒープのインデックスが適切に作成されておらず、ETLが重い悪いアプリを使用して、一度しか見たことがありません。
これはゴミであり、幸いなことに私のものではありません。
それ以外の場合、理由はありません。
不適切な時間に統計の更新を取得している場合は、インデックス/統計のメンテナンスが正しく行われていないか、大量の削除/ロードがしきい値に達していることを意味します。
SQL Server 2005+では、とにかく統計の更新を延期できます。「同期または非同期の統計更新を使用する場合」を
参照してください
この選択を行うために、彼らがどの記事を読んだか読んでいるのかは興味深いでしょう...
昔（SQL Server 2000）で統計の自動更新をオンにすると、SQLが統計の更新を決定したときにOLTPアプリケーションで大きな「一時停止」が発生することがありました。
SQL Server 2005以降では、統計が古くなって再コンパイルされたときに「一時停止」にならない非同期オプションがあります。統計は、次回必要になったときに非同期で再コンパイルされます。
ただし、バランスを取る必要があることに注意してください。大規模なデータセットの場合、クエリは非効率的なクエリプランでは指数関数的に時間がかかるため、現在のクエリで最新の統計を考慮する必要があります。
また、SQL Serverによって公開されているperfmonカウンターを使用して、1秒あたりの再コンパイル数やその他の重要なパフォーマンスメトリックを監視できます。
システムはどの程度アクティブですか？
ほとんどが読み取りシステムである場合、データを変更（挿入、更新、削除）しているときに更新を手動で行うと、更新せずに済む可能性があります。
ただし、ベストプラクティスとしては、原因を把握しておくことをお勧めします。パフォーマンスの問題になることはまれだと思います。私はおそらく彼らに記事とブログ投稿を送って、それを残しておくことを提案します。キンバリー・トリップには良いものがいくつかあります。
私は決して矛盾したり、意図的にMrDennyを否定したりはしませんが（彼の知識とコミュニティへの貢献を尊重しすぎています）、MSのドキュメントで自動更新統計をオフにすることを推奨しています。
で、ストレージおよびSQL Serverの容量計画と構成（SharePoint Server 2010の） MSはそれをオフに設定をお勧めします。
また、以前のバージョンのSPに関するMSの同じ推奨事項を読みましたが、今すぐリンクを見つけることができません。
しかし、私はSPエキスパートDBAではないため、MS PermierフィールドエンジニアであるChun LiuがSharePointの Chun Liuで何を言っているかを確認するか、この投稿を無視してそのままにしておくこともできます。
通常は、自分で更新する方法がある場合にのみオフにします。自動統計が行うよりも良い、または単に異なるサンプリングが必要なので、私はこれを常に行います。それはかなり一般的ですが、単純にオフにして他に何もしません。