なぜこのような状況でfillfactorを低い値に設定するのですか？

Question

SQL Serverを使用するOLTPシステムがあるとします。たとえば、テーブルにクラスタード・インデックスがあるとします。

私に以下の質問にいくつか答え教えてください：あなたが唯一のインデックス順に従って新しいレコードを挿入した場合

を、ページ分割はページのみに制限されます - またはそれ以降に - 存在していた最後のページあなたの最後のインデックスの再構築時に、正しい？

つまり、インデックス順に続く新しいレコードだけを挿入した場合、最後のインデックス時に存在していた最後のページよりも前にあるページ（順番どおり）にページが分割されることはありません再建、正しい？

つまり、既存のインデックスの途中にレコードを挿入しようとしない限り、あなたのページの最後にあった最後のページの前にあるページでページ分割が行われることはありません最後のインデックス再構築、正しい？

上記の内容がすべて真である場合は、通常、既存のインデックスの途中にレコードを挿入しないでください。つまり、いつあなたはそのようなことをしたいのですか？

OLTPシステムのインデックスのfillfactorを低い値に設定する理由を正確に理解できないため、これらの質問をしています。私の考えは、「既存の索引の中央にレコードを挿入して索引を作成する計画がない場合は、各索引ページおよびデータ・ページの未使用の空き領域をすべて埋めるポイントは、アップ？"

私は、ページの分割は最後のページ（順序の賢明さ）から始まることを理解します。これは、最後のインデックスの再構築時に存在していたものです。しかし、既存のインデックスの真ん中にレコードを挿入する予定がないOLTPシステムで、誰かがfillfactorを低い値に設定する理由を、より詳細に説明できますか？

これがどのように機能するかを理解していない場合は、私にも知らせてください。

ありがとうございました。

Answer 1

FILLFACTORの理解は私の理解と一致します。

上記の内容がすべて当てはまる場合は、通常、既存のインデックスの途中にレコードを挿入しないでください。つまり、いつあなたはそのようなことをしたいのですか？

逐次キーを使用していない場合。すべてのクラスタ化インデックスがIDENTITY(1,1)フィールドの場合は、必ずただし、データベース全体のすべてのテーブルの場合はそうではありません。多対多リレーションシップのジャンクション・テーブルがある場合は、常にリレーションを追加することができます。 probablyの場合、そのテーブルにはIDENTITY(1,1)というキーが存在しないようにします。代わりにテーブルの外部キーの複合主キーにクラスタリングしている場合（使用することになるときに結合するため）、順次挿入を一切使用していません。

さらに、順次キーを使用しても使用しても、クラスタ化されないことがあります。 IDENTITY列以外のものにクラスタ化することは可能であり、しばしば望ましいことです。それはあなたのデータをどのように使用するかに依存します。イベントを保存していても、各サイトのイベントを90％の時間で照会する方法であるため、各サイトのイベントを一緒に保持したい場合は、イベントサイトをクラスタリングキーに含めることができます。

Answer 2

行ロックがページロックにエスカレートし、1ページあたりの行数が少なくなるため、影響を受ける行が少なくなる場合があります。 DMLが発生していない場合、すべてのロックは共有ロックである必要があります。

もう1つのシナリオは、ページに適合しない行を更新する場合です。私がしなければ、今

create table foobar (
    a int identity primary key clustered, 
    b varchar(1000) default 'a' 
); 

：以下の表を想像してみて

insert into foobar default values 
go 1000 

が、私は1つのページにそれらの行のすべてを得ることができます（多かれ少なかれ - フィルファクタが100であると仮定すると、各行4 + 1 = 5バイトを使います。私は行のオーバーヘッドがあることを知っていますが、デモを簡単にしましょう）。しかし、何が私がしなければ：

update foobar 
set b = replicate('a', 1000); 

は今、各行は4 + 1000年= 1004バイトを占め、私は1ページあたり≈7行を収めることができます。私はもっ​​とたくさんのページが必要です！しかし、フィルファクタが最初に低く設定されていた場合、（ページが1行しかないようにフィルファクタが設定されていない限り）いくつかのページスプリットが発生するでしょう。 SQL 2008以上をご利用の方は、拡張イベントでこれを調べてください。ページ分割のイベントがあります。

TL; DR - 更新でもページ分割が発生する可能性があります。

Answer 3

はい、インデックスfillfactorに追加すると役立ちません。

はい、ページの分割を引き起こすような方法でインデックスの中央に書き込むことは良いことではありません。

いつもインデックスに追加することはできません。ユーザー登録をWebフォーラムにインデックス登録すると、ユーザーは電子メール、ユーザー名、電話番号、電子メールアクティベーションキーの順にランダムに入力されます。 （IDや登録日などの順番で挿入されます）

ここでは、軽減する方法があります。

既存のインデックスの途中にレコードを挿入する計画がないOLTPシステムで、fillfactorを低い値に設定する理由は何ですか？

私はそれを実際にはしませんが、そのような純粋なOLTPシステムはほとんど存在しません。

データを別の順序で表示するのはインデックスのようなものです。面白いオーダーがお互いに整列しているわけではありません。