1

クラスター化インデックスには、インデックス フィールドだけでなく、すべての行データが含まれていることがわかりました。断片化に関して、これが意味することを理解しようとしています。

次のようなテーブルがあるとします。

create table Files
(
    ID uniqueidentifier not null,
    Field1 nvarchar(300) null,
    Field2 nvarchar(300) null,
    Field3 nvarchar(300) null,
    Binary varbinary(max) null
)

ここで、これらの行がすべてデータでいっぱいで、クラスター化インデックスの以前の行のいくつかで、Field1、Field2、Field3、および Binary を突然 null に設定したとします。

これが意味することの 1 つは、私の単純な考え方ですが、これらの値をすべて消去するとギャップが生じ、インデックスが断片化することです。行はまだ正しい順序になっていると思いますが、それは本当にインデックスの断片化ですか?

または、別の方法で考えることができます。それらがすべて最初から null で、データを挿入する場合、データを別のページにシャッフルしなければならず、インデックスの断片化も発生しますか?

さらに、LOB データが別のアロケーション ユニットに格納されていることは知っていますが、それが何を意味するのかはわかりません。Binary を null に設定 (または設定) しても、クラスター化インデックスの断片化には影響しないということですか?

4

1 に答える 1

1

これが意味することの 1 つは、私の単純な考え方ですが、これらの値をすべて消去するとギャップが生じ、インデックスが断片化することです。行はまだ正しい順序になっていると思いますが、それは本当にインデックスの断片化ですか?

はい。内部の断片化が発生します。SQL Server は、スペースを再利用するためにデータ ページを自動的に圧縮しません。これは、SQL Internals Viewerツールを使用して確認できます。ワークロードにもよりますが、これは必ずしも悪いことではありません。ある程度の内部断片化は、以下を軽減するのに役立ちます (また、FillFactor を使用して意図的に追加することもできます)。

または、別の方法で考えることができます。それらがすべて最初から null で、データを挿入する場合、データを別のページにシャッフルして、インデックスの断片化も発生させる必要がありますか?

はい。長い行に対応するための十分な空きスペースがページにないと仮定すると、新しいデータ用のスペースを確保するためにページが分割されます。論理的な順序は物理的な順序とは異なり、外部の断片化が発生します。

于 2010-09-27T09:22:22.133 に答える