インデックスの再構築はディスクからの物理的な読み取りを減らしますか
最近、Ola Hallengreenスクリプトを使用して、99％断片化されたインデックスを再構築しています。再構築後、物理的な読み取りが大幅に減少していることに気付きました。これは再構築されたインデックスと関係がありますか？
インデックスを再構築した直後は、そのページがメモリにキャッシュされる可能性が高くなります。
このシナリオを考えてみましょう：
- サーバーでさまざまなクエリが実行されており、さまざまなテーブルがメモリにキャッシュされている
- 特定のテーブル（テーブルのCOUNT（*）など）にヒットするクエリを実行し、そのすべてのページがメモリにキャッシュされていませんでした。クエリは多くの物理的な読み取りを行って、そのデータをキャッシュに入れます。
- インデックスを再構築します。
- クエリを再度実行しますが、今回はそのページがメモリにキャッシュされます。そのクエリに対する物理的な読み取りが少なくなります。
これは、物理的な読み取りを使用してパフォーマンスチューニング作業の成功を測定したくない理由の1つです。代わりに論理読み取りを使用することから始めます。 （つまり、ステップ＃3を完全に省略しても、物理的な読み取りが少なくなる可能性がありますが、物理的な読み取りを減らすためにすべてのクエリを2回実行する必要があるという意味ではありません。）
基本的な質問は、「インデックスの再構築がインデックスに対して何を行うか」ということです。簡単な答えは、インデックスを順番に配置することです。より複雑な答えはあなたの質問に対する答えであり、2つの部分に分かれています。
- 非クラスター化インデックス：非クラスター化インデックスでは、再構築により、インデックスで指定された順序でページが物理的に次々に配置されます。これには、断片化されたページをより少ない数のページに統合する効果があり、各シークでより少ないページを確認できるようになります。また、エクステントには同じインデックスのより多くのページが含まれる必要があるため、範囲のルックアップにも役立ちます。これは、以下よりも効果が小さくなります。
- クラスター化インデックス：クラスター化インデックスでは、インデックスは実際にはデータ行にアタッチされます。クラスタ化インデックスが断片化されている場合、インデックスページはディスク上で非順次であるだけでなく、データレコードも非順次です。繰り返しますが、これはどちらもインデックス内のページの総数を減らす傾向がありますが、インデックスとデータ行の両方を順番に並べ替え、特に範囲選択での検索を高速化します。
また、@ Laughing Vergilの回答に加えて、I/Oワークロードが削減された理由をもう1つ追加します。
インデックスが再構築された後、それらのインデックスの統計も再構築されます。つまり、より正確な統計が構築されます。そのため、以前（つまり、インデックスの再構築前）にテーブルスキャンを使用して処理を行っていたクエリが、インデックスシークを使用してその結果、I/Oワークロードが大幅に削減されました。