フィル ファクター 100% の一意のクラスター化インデックス myId を持つテーブル myTable があります。これはゼロから始まる整数です (ただし、テーブルの ID 列ではありません)。新しいタイプの行をテーブルに追加する必要があります。myId の負の値を使用して、これらの行を区別できるとよいでしょう。
負の値を使用すると、余分なページ分割が発生し、挿入が遅くなりますか?
追加の背景: このテーブルは、異種システムからデータを収集するデータ ウェアハウスの etl の一部として存在します。私は今、新しいタイプのデータに対応したいと考えています。これを行う方法は、この新しいデータに負の ID を予約することです。これにより、自動的にクラスター化されます。これにより、主要なキーの変更やスキーマ内の余分な列も回避できます。
回答の要約: 100% のフィル ファクターは通常、挿入を遅くします。ただし、順次発生する挿入ではなく、順次の負の挿入が含まれます。
合理的なシステムに気付くのに十分ではありません。
ページ分割は、範囲の開始時または終了時にページがいっぱいになると発生します。インデックスを定期的にメンテナンスしている限り...
編集、Fill factor コメントの後に:
90 または 100 FF でページを分割すると、各ページは 50% 埋まります。FF = 100 は、挿入がより早く行われることを意味するだけです (おそらく最初の挿入)。
厳密に単調に増加 (または減少) するキー (+ve または -ve) を使用すると、範囲の両端でページ分割が発生します。
ただし、BOL からは、FILLFACTOR
塗りつぶし
テーブルの最後にデータを追加する
新しいデータがテーブル全体に均等に分散されている場合は、0 または 100 以外のゼロ以外の FILL FACTOR を使用すると、パフォーマンスが向上する可能性があります。ただし、すべてのデータがテーブルの最後に追加されると、インデックス ページの空きスペースが埋まりません。たとえば、インデックス キー列が IDENTITY 列の場合、新しい行のキーは常に増加し、インデックス行は論理的にインデックスの末尾に追加されます。行のサイズを長くするデータで既存の行が更新される場合は、100 未満の FILL FACTOR を使用してください。
それで、厳密に単調なキーのfillfactorは重要ですか...？特に書き込み量が少ない場合
結果として生じるページ分割に関係なく、ここで作業中の根本的な設計上の問題があるように思われるという点で、この投稿が間違った方向に進んだ可能性があるのではないかと心配しています。
なぜ負のIDを導入する必要があるのですか？
たとえば、整数の主キーは行を一意に識別する必要があり、その符号は無関係である必要があります。そうでない場合は、テーブルの主キーに定義の問題がある可能性があります。
新しく挿入されたレコードにフラグを立てて識別する必要がある場合は、この目的専用の列を作成してください。
このソリューションは、主キーがシーケンシャルであることを確認できるため（必須ではありませんが、おそらくIdentityデータ型を使用して）、ページ分割（挿入時）の問題を完全に回避できるため、理想的です。
また、可能かどうかを確認するために、クラスター化インデックスの主キー（たとえば、ID整数）のフィルファクターが100％の場合、順次挿入のページ分割は発生しません。
あなたは間違った質問をしています！
fillfactor が 100% のクラスター化インデックスを作成すると、レコードが挿入、削除、または変更されるたびに、既存のインデックス データ ページに変更を書き込む余地がない可能性があるため、ページ分割が発生する可能性があります。
定期的なインデックス メンテナンスを行っても、挿入が実行されることがわかっているテーブルでは、100% のフィル ファクターは逆効果です。より一般的な値は 90% です。
いいえ、まったくありません。負の値は、正の値と同じように INteger と同じように有効です。問題ない。基本的に、内部的には、それらはすべて 0 と 1 の 4 バイトに相当します :-)
マルク