IDの主キーを持つクラスター化インデックスを持つ大きなテーブルがあります。ページ分割を最小限に抑えるために、このテーブルのFILL FACTORの正しい値を決定しています。断片化を測定して適切なアクションを実行するスクリプトを毎日実行して、インデックスを維持します。テーブルには可変長の列が含まれています。
私の最初の考えは100に設定することでした（レコードはテーブルの最後にのみ書き込まれるため）が、可変長の列を変更するとページ分割も発生する可能性があると想定し、90に向かっています。
助言をいただければ幸いです。
回答:
場合によります
それはバランスをとる行為です。テーブルが読み取り集中型で、更新や削除が少ない場合は、デフォルト（100）で問題ありません。
テーブルが非常に書き込み集中型で、更新が多い場合は、80未満の値が適切な場合があります。
これには魔法の公式はありません。（AFAIK、ある場合はお知らせください）テスト環境を用意し、ワークロードをテストするのが最善の方法です。変更を加え、ワークロードでデータベースがどのように機能するかを確認します。
ニックはかなり正しいです。
パックされたページのレコードのサイズを増やす更新を行うと、ページ分割が発生しますが、それとは別に、ID主キーを使用すると、クラスター化インデックスでページ分割が発生することはありません。
（とはいえ、ストレージエンジンが実行できるページ分割には5つのタイプがあり、それらすべてが断片化とデータ移動を引き起こすわけではありません。単調に増加するID値を挿入するときに得られるのは、ページ終了分割です。しかし、余談です...）
私はこれで多くの顧客を助けました、そして私はそれについてすべてBOLを書きました-あなたが地面の利害関係として価値を単に選びたいなら、70％が最も成功していると見ています。Nickが言うように、必要に応じて監視および調整します。
インデックスのFILLFACTORを選択することは、ページの占有率を100％に押し上げるアクティビティの発生量と、FILLFACTORをリセットするための修正アクションを実行できる頻度のバランスをとる行為です。fillfactorを50％のように非常に低く設定した場合、ページ上で最初にどのくらいのスペースが「無駄」になるかを考える必要がありますが、これも適切な場合があります。
また、インデックスの使用方法も考慮する必要があります。シングルトンルックアップだけの場合は、メモリ内にまばらに設定された多くのクラスター化インデックスを持つことでIO /メモリを浪費しすぎないので、fillfactorが低くなり、再構築/デフラグ間の時間が長くなります。大規模な範囲スキャンを行う場合は、IOとメモリの効率を高めるために、fillfactorを少し高くする必要があります。
OLTPとDWの問題もあります。通常、DWは不変なので、インデックスのフィルファクターは100％になります。OLTPは難しい部分です。
クラスタ化インデックスを整理した後、非クラスタ化も断片化する可能性が高いため、注意が必要であることを覚えておいてください。
fillfactorをリセットするときは、再構築とデフラグのどちらかを選択できることに注意してください。DBCC INDEXDEFRAG / ALTER INDEX ... REORGANIZEは、不適切にフラグメント化されていないインデックスの場合に、fillfactorをリセットできます。
お役に立てれば！
（「過剰回答」で申し訳ありません-私のホットボタンの1つで、コードを書いた:-)