フィルファクターに基づくインデックス内のデータの動作

デフォルトのFILL FACTORが20のデータベースがあるとします。データが挿入されるたびに、最大20％のページのみが作成されますか？

私の理解では、データが挿入されると、ページ内のデータの約20％になります。ただし、データが更新されると、インデックスの20％以上に拡張され、データがいっぱいになってページ分割が生成されます。

FILL FACTORは、インデックスが作成または再構築されたときにのみ機能します。 これらの操作中に満たされるのは、リーフレベルページのインデックスの消費量です。（影響を受けるページレベルの詳細については、以下の注を参照してください）

データへのDMLコマンドがある場合（INSERT、UPDATEおよび/またはDELETE）、それは、対応する影響を受けたインデックスに起こります。つまり、20％のページがあり、そのページにデータを挿入すると、そのページには20％を超えるデータが含まれます（たとえば、35％としましょう）。別の挿入を行うと、ページは64％埋められます。インデックスを再構築すると、リーフレベルのページに、指定したスペースの割合（または暗黙的にサーバーのデフォルト値）が相対的に含まれるようになります。

（注：を指定PAD_INDEXしない場合ON、Fill Factorはリーフレベルのページにのみ適用されます。ただし、を設定するPAD_INDEX = ONと、Fill Factorはインデックスの中間レベルのページで考慮されます。 デフォルトはですOFF）

（デフォルトの100/0を使用する代わりに）フィルファクタを調整する理由は、データの挿入または更新時にページ分割を最小限に抑えるためです。しかし、心に留めておいてください、無料のものは何もありません。フィルファクタが低いほど、通常より多くのスペースデータが使用されます。インデックス用に80％の空きページスペースを保持すると、比較的多くのディスクスペースが消費され、読み取りが増える可能性があります。

私の理解では、データが挿入されると、ページ内のデータの約20％になります。ただし、データが更新されると、インデックスの20％以上に拡張され、データがいっぱいになってページ分割が生成されます。

データが挿入されると、適切なページの適切なインデックスに挿入されます。 これにより、ページ消費量がFILL FACTORよりも高くなる可能性があります。

新しいデータが完全なインデックスページに追加されると、ページ分割が発生します。 その後、SQL Serverはページを分割し、フルページのデータの約半分を新しいページに配置します。繰り返しますが、フィルファクターはここでは機能しません。

フィルファクターを低くする正当な理由は、ページ分割を最小限に抑え、インデックスページの断片化を最小限に抑えることです。