* インデックスのリーフページ (インデックス B-Tree の最下層ページ) を構成する
ページの論理的な並び順と物理的な並び順が異なっている度合いを表わす
* 論理スキャンフラグメンテーションの値が大きいほど、断片化の度合いが大きい
* インデックスの総ページ数を分母とした値であるため、インデックスの総ページ数が少ない
(小さなインデックスでは、必然的に大きな値になる)
結論から言うと...
大量のデータを読み取る処理でなければ、ほとんど影響はなさそう
* 読み取りを行うために必要となる API 呼び出しの回数は変わる可能性がある
* 先行読み取り (read ahead) の効率が落ちる可能性がある
平均ページ密度
* テーブル又はインデックスに関して、1ページ (8KB) に、平均どの程度データが詰まっているのかを表わす
* 値が低いほど断片化の度合いが大きい（1ページあたりに格納されているデータ量が少ない）
* 平均ページ密度は、必ずしも 100% にはならない
平均ページ密度が低くなると起こる弊害
* ページ密度が低くなると、パフォーマンスが悪化する
【理由】
* 低い場合、多くのページを読み取る必要がある、つまり、読み取り量が多くなる
=> ファイルから読み取る量が多くなれば、読み取りのために必要な時間は長くなる
=> 読み取る量が多くなれば、それをキャッシュするために必要なメモリも多く必要になる
■ 技術編
断片化情報を調べる
DBCC SHOWCONTIG(【テーブル名】)
出力例
スキャンされたページ数......................: 10219
スキャンされたエクステント数................: 3046
切り替えられたエクステント数................: 3224 ⇒「スキャンされたエクステント数」に近い方が良い
エクステントごとの平均ページ数..............: 6.6
スキャン密度 [最善 :実際]...................: 78.39% [2528:3225] ⇒100未満は断片化発生★重要★
論理スキャン フラグメンテーション ..........: 0.93% ⇒0に近い方が良い
エクステント スキャン フラグメンテーション .: 58.54% ⇒0に近い方が良い(ｲﾝﾃﾞｯｸｽが複数ﾌｧｲﾙに渡す場合値が高くなる)
ページごとの平均空きバイト数................: 172.4 ⇒低い方が良い
平均ページ密度 (全体).......................: 96.65% ⇒高い方が良い★重要★
断片化を解消するには？
* インデックス再構築を行う
