ID列にあるクラスター化インデックスのFILLFACTORを100にしても問題ありませんか？
したがって、SQL ServerのID列（自動インクリメント列）にクラスター化インデックスが設定されたテーブルがあります。
データは常に次の最新IDで書き込まれるため、これに100の曲線因子があっても問題ありませんか？このテーブルの他の列が既存のIDに対して多く更新されるかどうかは重要ですか？
また、削除はテーブルの断片化にどのように影響しますか？
ほとんどの場合、doには100のFILLFACTORが必要です。その値を下げるのは、特別な場合のみです。更新では、行のサイズを増やして同じデータページに収まらない場合にのみ、ページ分割が発生します。ここで削除すると、どちらの場合も関係ありません。すべての場合において、断片化が特定の制限を超えている場合は、定期的なインデックスメンテナンスとREBUILDのクラスター化インデックスを実行する必要があります。 Rebuildはすべてのデータを理想的な順序に再ソートするため、古いデータページまたは新しいデータページ、あるいはその両方にまだ利用可能なスペースがある場合に、ページ分割を引き起こしたDELETEオペレーションおよびUPDATEオペレーションによって残された空白を埋めます。
多くの削除は空のページを残す可能性があり、したがって一部の断片化が発生する可能性がありますが、より低いFILLFACTORを使用しても役に立ちません。実際、削除される行によっては、最初に各データページに表示される行が少なくなるため、空のページの断片化が増える可能性があります。
ただし、次の点に注意してください。
FILLFACTORに100を使用しても、スペースの100％が使用されるわけではありません。行全体のスペースがある限り、行はデータページに収まります。 100バイトが残っていて、105バイトの行を追加する場合は、そこに収まりません。ただし、可変長の列を更新するためのスペースが50バイト増加します。FILLFACTORを100未満に設定すると、更新されるページだけでなく、allデータページのスペースが予約されます。テーブル/インデックスの範囲全体に更新を均等に分散する使用パターンがない場合、更新されていない「古い」行を含むデータページにスペースを予約するのはなぜですか？新しいデータページの一部（つまり、更新される可能性が高い行）がページ分割されないことを期待して、インデックス/テーブル全体のクエリを遅くするだけですをできるだけ早くFILLFACTOR/100。行のサイズと、
FILLFACTORが100の場合にデータページに何行が収まるか、90や80などの低いFILLFACTORのデータページに何行が収まるかを検討します。500〜1000の広い行がある場合バイト、さまざまなFILLFACTOR値の違いは1行または数行の場合があります。どのような種類の更新が行われていますか？更新が固定長の列に対するものである場合、これは問題にもなりません。可変長の列の場合、サイズを100〜500バイト増やすことができますか？ここで本当に実用的であると考えるいくつかの要因があります：1日または1週間（
REBUILD操作間の長さ）の中で、並べて並べられた行に対する連続するUPDATE操作がサイズを拡大し、複数のページ分割を引き起こす場合、そのページを数時間または1日で分割することを延期しますentire table/index全体でそのスペースを予約することの影響に見合うだけの価値があるため、より多くのディスクスペース、メモリ内のスペース（バッファプールなど）を占有します）、バックアップを大きくする、ディスクからバッファプールに読み込むのに時間がかかる、インデックスのメンテナンスに時間がかかるなど- フラグメンテーションは、シングルトンクエリではなく、範囲クエリに悪影響を及ぼします。個々の行をフェッチしている（または更新または削除する行を見つけている）場合、少なくとも実際に不良になるまでは断片化の影響はわかりませんが、おそらくまったくそうではありません。
多くの/ほとんどの技術的な決定と同様に、「最良の」または「最適な」アプローチに影響を与えるさまざまな技術があります。したがって、更新が可変長列に対して行われる場合、更新アクティビティが主にテーブル/インデックス全体に分散される場合、またはより「最近の」セグメントに限定される場合は、行の最大サイズを考慮する必要があります。など。私は、すべてのテーブルのFILLFACTORが80になるようにポリシーが設定されていた場所で作業しましたが、クラスター化インデックス（通常はPK）と「古い」にIDENTITY列を使用しているので、それは非常識な（そして無責任な）慣行でした。データが更新されることはほとんどありません。したがって、無駄なtonsの高額なSAN多くのテーブルのスペース-多くの場合100万行を含む-）は、バックアップを膨らませました（そして、両方のバックアップ操作を行いましたおよび復元操作には時間がかかります！）、より多くのメモリが消費され、キャッシュされたプランが強制的に強制排除またはキャッシュされたデータページになります（つまり、ページの期待寿命が非常に低かった）。
ERGO： 100から始めて、最適化が必要と思われる場合にIF/WENを少しずつ減らして実験します（つまり、特定のテーブルのフラグメント化が再構築と次の再構築の間でより高いレベルに成長していることがわかった場合。パフォーマンスの低下も引き起こします！）。
断片化度が高い場合を除き、デフォルトのFILL FACTORを100に維持する必要があります。テーブルが完全にメモリ内に保持されている場合、 Fill Factor Impact が大幅に減少することに注意してください。レコードが単に更新されているだけの場合、スペースの場所に収まると想定しないでください。前のレコードがあった場所に収まるよりも多くの情報でレコードが更新された場合（およびページがいっぱいの場合）、レコードを別のページに移動する必要があります。
this を読んで、削除が実際に断片化を引き起こす方法を理解してください。