問題タブ [fillfactor]

通常、テーブルにインデックスを作成するときはFill Factor、テーブルがどのように使用されるか (多くの読み取りまたは多くの書き込み) についての知識に基づいた推測に基づいて、何をすべきかを推測します。

Fill Factorより正確な値を決定するためのより科学的な方法はありますか?

MySql でインデックスを作成するときに、フィル ファクターをどのように指定しますか?

私はオンラインで本をトロールし、リーフページ（SQL Server 2000および2005）で物理的にどのフィルファクターが存在するかを調べようとグーグルの呪文を唱えてきました。

インデックスが作成されたときにページに残されたスペースの量は理解していますが、私が見つけていないのは、そのスペースが実際にどのように残されているかです。つまり、ページの終わりに向かって1つの大きなチャンクであるか、そのデータにはいくつかのギャップがあります。

たとえば、[簡単にするために]、ページが100行しか保持できないと仮定します。フィルファクターが75％であると記載されている場合、これは、ページの最初（または最後）の75％がデータであり、残りが空いていることを意味しますか、それとも4行ごとに空いていることを意味します（つまり、ページは次のようになります：データ、データ、データ、無料、データ、データ、データ、無料、...）。

これの長所と短所は、クラスター化されたインデックスを持つテーブルに行を挿入するときに発生する物理操作に関して正確に何が起こるかを把握していることです。挿入は行の最後では発生しません。 。ページ全体に複数のギャップが残っている場合、挿入に対応するために移動する必要のある行数が最小限に抑えられるため、挿入による影響は最小限に抑えられます（少なくともページが分割されるまで）。ギャップがテーブル内の1つの大きなチャンクにある場合、行を調整するためのオーバーヘッドは（少なくとも理論的には）大幅に大きくなります。

誰かがMSDNリファレンスを知っている場合は、それを教えてください！現時点では見つかりません（まだ探しています）。私が読んだことから、それは多くのギャップがあることを意味します-しかし、これは明確に述べられていないようです。

SQL Server 2005/2008でテーブルの読み取り数と書き込み数に関する統計を見つける方法はありますか?

DMVs/DMFsトリガーや監査を使用せずに特に探しています。

ここでの目標は、インデックスの適切な FILL FACTORを見つけることです。この記事 ( FILL FACTOR DEFINED ) からアイデアを得ました。

[更新] ServerFault に関するフォローアップの質問があり
ます DMV/DMF 統計から読み取り/書き込み集中テーブルを決定する方法

約1000ページ、95％の断片化、FillFactorが「0」の非クラスター化インデックスがあります。

日曜日にインデックスを再構築しました。1週間後、インデックスには再び95％（またはそれくらい）の断片化があります。これは、FillFactorを80〜90％に変更する必要があることを示していますか？

週ごとに断片化を減らすことができるかどうかを確認するために、毎週フィルファクターを微調整する必要がありますか？狙っている目標レベルはありますか？

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

PostgreSQL 8.4で既存のテーブルのfillfactorを変更することは可能ですか？

または、新しいfillfactorを使用してテーブルのコピーを作成する必要がありますか？これは、外部キーの問題のために最善のアプローチではありませんか？

データベース内のすべてのテーブルの主キーのフィルファクター引数を変更するための実用的な方法はありますか？

はい、fillfactorまた。私は何時間も読んでいますが、それぞれのケースに何が最適かを判断することはできません. 断片化がいつ、どのように発生するのかわかりません。データベースを MS SQL Server から PostgreSQL 9.2 に移行しています。

ケース1

シーケンシャル (シリアル) PK で 10 ～ 50 回の挿入/分、20 ～ 50 回の読み取り/時間。

ケース 2

同様の構造であるシリアル PK のインデックスは、2 か月ごとに ~ 50.000 レジスタのブロック (ワンショット) に書き込み、読み取りは 10-50/分です。

50% の fillfactor は、各挿入が新しいページを生成し、既存の行の 50% を新しく生成されたページに移動することを意味しますか?

50% のフィルファクターは、新しいデータ ページの物理行間に空き領域が割り当てられることを意味しますか?

既存のページに空き領域が残っていない場合にのみ、新しいページが生成されますか?

ご覧のとおり、私は非常に混乱しています。PostgreSQL と index について読むための良いリンクかもしれませんfillfactor。

Binary(128) 列を持つテーブルがあります。Varbinary(128) ではなく Binary(128) を選択したため、128 バイトすべてが予約され、バイナリ値の更新時にページ分割が防止されます。テスト目的で、インデックスに 100 の FILLFACTOR があります。

列が Binary(128) 値に設定されていても、この列の更新を実行するとページ分割が発生することがわかりました。

誰でも理由がわかりますか？

テストするコードは次のとおりです...

FILLFACTOR を 100 にして大規模な更新を実行すると、深刻な断片化が発生しますが、FILLFACTOR を 90 にすると、すべて問題ありません。非 var データ型はメモリを予約するはずなので、この問題に遭遇しないと思いました。ストレージのインフレはどこから来ているのか?

ありがとう！