STATISTICS_NORECOMPUTEの使用の妥当性
最近、いくつかの興味深いインデックスの問題がある一連のデータベースの保守に携わってきました。私を最も悪化させるものの1つは、開発、テスト、モデル、および生産マシン間のインデックスの違いです。違いがあるため、クエリのチューニングがかなり難しくなるため、クエリの同期は私の最初のプロジェクトの1つです。
テスト環境とモデル環境を比較したところ、モデル環境のほとんどのインデックスでSTATISTICS_NORECOMPUTEがONに設定されているのに対し、テスト環境ではそうではないことに気付きました。すべての環境で、すべてのデータベースの統計を更新する夜間ジョブがあります。
これまでSTATISTICS_NORECOMPUTEを扱ったことがないので、ここで私の質問です。この設定を扱う際のベストプラクティスはありますか？ 1日の終わりに統計の更新を行う場合、すべてのインデックスのすべての環境でSTATISTICS_NORECOMPUTEをオンにするのが最善ですか？それとも、正当な理由がないのですか？
編集：私はこの件についてキンバリートリップのブログの1つを見つけました hereSTATISTICS_NORECOMPUTEは控えめに使用する必要があることを示唆しているようです。しかし、私はまだそれをグローバルにオフにすることを心配しています。誰かがこれを試しましたか、そして彼らは何を経験しましたか？
これは実際にはテーブルごとまたはインデックスごとに確認する必要がある状況的なものであり、アクションを実行する前に、実際に何が生成されているかを確認する必要があります。疑わしい場合は、他の環境でも本番環境のものを使用してください。たとえそれがクレイジーな設定を使用することを意味する場合でもです。テストや開発で状況が異なる場合、本番環境での動作がよくわかりません。
とにかく、自動更新の統計情報をオンにしたままにするための一般的な推奨事項（STATISTICS_NORECOMPUTE = OFF（これがデフォルトです）は安全上の理由からです。これがオフになっていて、統計を手動で更新していない場合、結果は最初に作成された後に変更されない（そして取得しない）恐ろしい実行プランになる可能性があります後で他の理由で無効になります）。
mostインデックスの統計の自動更新がオフになっているとおっしゃっていました（元々はall、ではないmost）。自動更新統計がまだ有効になっているインデックスの場合、これらのテーブルでのアクティビティを考えると、この設定は意味がありますか？これらはより活動度の高いテーブルであると思います。それを理解するために多くの作業が行われた可能性があり、それらの設定を維持する（または強く検討する）価値があるかもしれません。少なくとも、これらの統計がどの統計であるかを書き留めてください。これは、情報がすぐに役立つ可能性があるためです。
もっと考えてみれば、現在の戦略には意味があると思います。すべてに対して自動更新統計をオンにしておくよりも良いですか？誰かがそう思っていたようですが、関連するSQLエージェントジョブを使用することで、管理のしやすさのトレードオフに値するものでした。
クエリをブロックせずに新鮮な統計を利用できるようにする場合（ this など）、すべてに対して自動更新をオンに戻し、次に AUTO_UPDATE_STATISTICS_ASYNC も同様です。次に、統計を更新したいので、おそらく、ジョブスケジュールを変更して、毎日ではなく週1回実行するように変更しますWITH FULLSCAN定期的に。
ただし、インデックス自体が環境間で異なり、統計情報の再構築にそれほど苦痛がなければ、おそらく大きな魚を揚げる必要があるので、私はそのままにするかもしれません。今あるものは理にかなっています。環境全体で一貫性を保つ必要があるだけです。より多くの作業が行われる代わりに、私が提案した単純な設定よりもわずかに良いでしょう。しかし、何が生産されているかを調べ、それを使用する傾向にあり、より重要なことに移ります。パフォーマンスをさらに細かく調整する必要が生じたときにこれを再確認してください。世界で最も優れた統計では、重要なインデックスがないクエリは保存されません。