STATISTICS_NORECOMPUTEの使用の妥当性

最近、いくつかの興味深いインデックスの問題がある一連のデータベースの保守に携わってきました。私を最も悪化させるものの1つは、開発、テスト、モデル、および生産マシン間のインデックスの違いです。違いによりクエリのチューニングが難しくなるため、クエリの同期は私の最初のプロジェクトの1つです。

テスト環境とモデル環境を比較したところ、モデル環境のほとんどのインデックスがSTATISTICS_NORECOMPUTE設定されているのONに対し、テスト環境のインデックスはそうではないことに気付きました。すべての環境で、すべてのデータベースの統計を更新する夜間ジョブがあります。

私はこれまでに対処したことがないSTATISTICS_NORECOMPUTEので、ここに私の質問があります。この設定を扱う際のベストプラクティスはありますか？1日の終わりに統計の更新を行っている場合STATISTICS_NORECOMPUTE、すべての環境ですべてのインデックスをオンにするのが最善ですか？それとも、正当な理由がないのですか？

編集：私はここでこの件に関するキンバリートリップのブログの1つを見つけましたが、それSTATISTICS_NORECOMPUTEはせいぜい控えめに使用する必要があることを示唆しているようです。しかし、私はまだそれをグローバルにオフにすることを心配しています。誰かがこれを試しましたか、そして彼らは何を経験しましたか？

テーブルごとまたはインデックスごとに確認したいのは実際の状況であり、アクションを実行する前に、実際に何が生成されているかを確認する必要があります。疑わしい場合は、他の環境でも本番環境のものを使用してください。これは、クレイジーな設定を使用することを意味します。テストまたは開発で状況が異なる場合、本番環境での動作がよくわかりません。

とにかく、自動更新統計をオン（STATISTICS_NORECOMPUTE = OFFデフォルトは）のままにしておくことの一般的な推奨事項は安全上の理由によるものです。これがオフになっていて手動で統計を更新していない場合、結果は変更されない本当に恐ろしい実行プランになる可能性があるためです。最初に作成された後（後で他の理由で無効化されないように）。

あなたは、自動更新の統計がオフになっていると、ほとんどのインデックス（私はもともと読み違えると思うと、すべてではなく、ほとんど）。自動更新統計がまだ有効になっているインデックスの場合、これらのテーブルでのアクティビティを考えると、この設定は意味がありますか？これらはより活動度の高いテーブルであると思います。それを理解するために多くの作業が行われた可能性があり、それらの設定を維持する（または強く検討する）価値があるかもしれません。少なくとも、これらの統計がどの統計であるかを書き留めてください。これは、その情報が後で役立つ可能性があるためです。

もっと考えてみれば、現在の戦略には意味があると思います。すべてに対して自動更新統計をオンにしておくよりも良いですか？誰かがそう思っていたようですが、関連するSQLエージェントジョブを使用することで、管理のしやすさのトレードオフに値するものでした。

（このように）クエリをブロックせずに新しい統計を利用できるようにするという考えの場合は、すべてに対して自動更新をオンに戻し、その後オンにすることも検討できAUTO_UPDATE_STATISTICS_ASYNCます。次に、統計をWITH FULLSCAN定期的に更新する必要があるため、おそらく、ジョブスケジュールを変更して、毎日ではなく週1回実行するようにします。

ただし、環境ごとにインデックス自体が異なり、統計情報の再構築にそれほど苦痛がなければ、おそらく大きな魚を揚げる必要があるので、私はそのままにするかもしれません。今あるものは理にかなっています。環境全体で一貫性を保つ必要があるだけです。より多くの作業が行われることを犠牲にして、おそらく私が提案した単純な設定よりもわずかに優れています。しかし、何が生産されているかを調べ、それを使用する傾向にあり、より重要なことに移ります。パフォーマンスをさらに微調整する必要が生じたときにこれを再確認してください。世界で最も優れた統計では、重要なインデックスがないクエリは保存されません。