私は8年以上前（この記事の執筆時点）に開始されたスレッドをネクロしていることを完全に理解していますが、NEWID（）、NEWSEQUENTIALID（）、 "Ever-increasing-INTs"、および私が単に「ExpAnsiveUpdates」（「A」を使用）と呼んでいるもので、実際にはExp E nsive（「E」を使用）です。
最初に後者について説明しましょう。これはおそらくOPが抱えている本当の問題です...
わずかな違いがありますが、ページ分割の不要な作成とその結果の断片化に関してはそれほど重要ではありませんが、NEWSEQUENTIALIDと「Ever-increasingINTs」はどちらも同じように機能します...それ自体では、「良い」ページ分割（これも「悪い」ですが、それは別の議論の主題です）。したがって、Opが、完全にランダムなNEWIDから「増え続ける」NEWSEQUENTIALIDに切り替えても、作成されていた断片化の量に違いはないようだと述べた、最初に投稿された質問を参照してください。
その理由は、NEWSEQUENTIALIDに問題があるという事実ではありません（問題はありません）。断片化の問題は、新しい行が挿入されている可能性が高く（これにより、NEWSEQUENTIALIDによる断片化は発生しません）、それらの新しい行は、それらを更新するための別のプロセスを受けます。更新が「 ExpAnsive」では、行の可変幅の列の幅が広くなり、大量のページ分割が発生します。これは、かなり低いFILL FACTORでインデックスを作成した場合でも発生します。これは、INSERTがページに到達したためにページへの挿入を停止しないためです。 FILL FACTOR。代わりに、多数の挿入がほぼ100％いっぱいになるまでページに挿入され（挿入される行の幅に依存するページあたりの行数に応じて）、「増え続ける整数を使用しているかのように、実質的に断片化のない「良い」ページ分割。
したがって、これらの行をすべて連続したページに挿入すると、可能な限り100％近くまで埋められます。すべてが正常です...断片化はありません。ただし、挿入したばかりの行を更新する「挿入後処理」を実行します。「 ExpAnsive」のために行のサイズが大きくなった場合は、 KAAAA-BOOOOOM !!! それらの完全に完全なページはすべて分割されてしまいます。
このような拡張の最も一般的な原因の1つは、人々が「貧乏人の監査」を使用し、NULLからある値に変化する「Modified_BY」列を持っている場合です。その特定の問題を修正する方法はたくさんありますが、繰り返しになりますが、このスレッドと投稿の範囲をはるかに超えています。
NEWID（）によって生成されたランダムなGUIDにギアをシフトする...それらを使用しない理由はたくさんありますが、あなたが信じさせられたものとはまったく逆に、断片化は実際にはそれらの1つではありません。私はそれを証明する非常に「アリスのレストランファッション」（たくさんのグラフィックとグラフィックの表記）でいくつかのプレゼンテーションをしました。この投稿に適した1時間以上のプレゼンテーションを作成するために、それはすべて、人々が犯し続けるいくつかの小さな、しかし致命的な間違いに要約されることをお伝えします...
おそらく「ベストプラクティス」が主な問題であるため、彼らはREORGANIZEを使い続けています。彼らは、REORGANIZEが実際にGUIDに対して機能しないことに気づいていません。ページに余分なスペースを提供する代わりに、実際には余分なスペースを削除します。つまり、私の仲間のインデックスラングラーは、実際にはGUIDの断片化を永続化します。ランダムガイドでインデックスのメンテナンスを行う場合は、REORGANZEを使用しないでください。限目！！！ExpressまたはStandardEditionを使用している場合でもそうではありません。再構築するための時間、リソース、またはディスクスペースがない場合は、REORGANZEを使用して間違って行うよりも、ランダムGUIDでインデックスのメンテナンスを行わない方が実際には適切です。REBUILDができるようになるまで待ちます。
ランダムなGUIDキー付きインデックスには低いFILLFACTORを設定する必要があります。それらを「0」のままにしておくことは、それらを再編成することとほぼ同じくらい悪いことです。もちろん、インデックスの行の幅、1日に挿入される行の数、およびランダムGUIDでのページ分割が完全にゼロ（「適切な」ものとは見なされない場合もあります!!!）を使用する期間によって異なります。インデックスでは、FILL FACTORを71、81、または91に設定するように指示します。これらすべてを「1」で終わらせる理由は、「ExpAnsive」の更新時にランダムGUIDを修正する必要があるためです。存在しません。これは、以下の項目＃3です。
毎晩、ランダムなGUIDに基づくインデックスを確認する必要があります。「1」で終わるすべてのFILLFACTORを指定した理由は、それが論理フラグメンテーションの％として探しているものだからです。インデックス全体のほぼすべてのページが分割されるポイントにあるため、1％を超えるとすぐに、それらを再構築する必要があります。（私はこれらを「低しきい値再構築」と呼んでいます）。さて、混乱しないでください。すべてが正しく設定されていて、「ExpAnsive」更新がない場合、GUIDキーのクラスター化インデックスはページ分割や関連する断片化なしで数週間かかる可能性があり、はるかに狭い非クラスター化インデックスは文字通り断片化なしでMONTHSになります。
もう1つの大きな間違いは、もちろん「ExpAnsive」の更新です。それらはほぼすべてを殺しますが、驚くべきことに、ランダムGUIDは、上記と同じ手順を使用して、他のほとんどのものよりもはるかに優れた猛攻撃を実際に乗り越えます。
本当に必要なのは、「ExpAnsive」アップデートを修正して、「ExpAnsive」ではなくなるようにすることです。私が言ったように、それはこの投稿を待ち望んでいる全体の主題です。