私は複合キーにクラスタード・インデックスを持つ3つの非常に大きなテーブルを持っています。更新は挿入されません。新しい挿入は既存のインデックス範囲内にはありませんが、新しい挿入がクラスタードインデックスと揃っていないため、これらのテーブルには多くの挿入が発生します（毎秒数千〜千）。何がしたいのかは、Fill Factor = 100のDBREINDEXですが、次にFill Factor 5を設定し、Fill FactorはInsertにのみ適用します。現在、Fill Factorはテーブル全体にのみ適用されます。挿入（または挿入と更新）にのみ適用されるフィルファクタを持つ方法はありますか？私はこの時点で選択スピードを気にしません。私はデータをロードしています。データの読み込みが完了すると、DBREINDEXは100になります。充填率が10対30の場合、新しいデータが挿入される割合は2倍になります。このロードには数日かかり、データがロードされるまでは実行できません。クラスタード・インデックスは、エンド・ユーザー・アプリケーションが使用する優位な照会と整列します。塗りつぶし係数と挿入速度
私のプラクティスは毎日DBREINDEXですが、問題はテーブルが大きくなっていることです。10 DBREINDEXは長い時間がかかります。私は "毎日の"テーブルへのインデックス作成を検討し、そのデータを毎日クラスタリングされたインデックスでソートして本番表に挿入しました。
これをさらに読むと。インデックスはすべてコンポジットであり、私は8コアサーバー上でパーサーの6つのインスタンスを実行しています（多くのテストとそれは最高のスループットを持つようです）。 SINGLEパーサからのデータはPK順であり、一度に990個の値を挿入します（SQL値の制限）。 3つのアクティブな表は、1つの相対的な非アクティブな第4の表との外部キー関係を介してのみデータを共有します。この時点で私の考えは、各パーサーのテーブルを保持し、次の完全な挿入のためにそれらのテーブルをポーリングし、データをPKの順序で本番テーブルに移動する別のプロセスを持つことです。それはたくさんの仕事になるだろう。誰かがより良いアイデアを持っていることを願っています
パーズはPK順序で開始しますが、ほとんどPK順序で終了しません。いくつかの個々の解析は非常に大きいので、最後までメモリ内のすべてのデータを保持することができませんでした。現在、SQLの挿入は、データを作成する構文解析よりもわずかに高速です。個々の解析では、insert asynchを実行し、解析を続けますが、以前の挿入が完了するまで挿入しません。
私はあなたがパーサーデータのためのテーブルを保持し、準備ができたらメインテーブルにのみ挿入する必要があることに同意します。以前の人生でも同様のことを実装しました（一意のIDのmod 10に基づいて10個の表に準ハッシュされ、その後主表にロールバックされました。 –
そして、あなたが保持テーブルを使うつもりなら、FF = 100でそれらを持つ必要はありません。より少ないページを使う必要があります。 –
@AaronBertrandありがとうございます。のようなものです）それは以前の下に来るように順序を終了します。パースの終わりに、フィル・ファクタをプロダクション・テーブルに挿入する必要がある場合は、挿入します。テーブルの塗りつぶし係数が100でインクリメンタルなページ分割がある場合、そのページ分割は50ですか？私のためには理想的だろう。 – Paparazzi