1

私たちの実稼働データベースでは、テーブルの 1 つで毎日インデックスを最適化する必要があります。テーブルにはいくつかのインデックスがあり、そのうちの 1 つが毎日 90% の断片化に達します。

インデックスは 2 つの日付フィールド (開始時刻と終了時刻) にあります。

開発データベースではこの問題は発生しませんが、明らかにスループットが大幅に低下します。

毎晩デフラグを実行するメンテナンス タスクがスケジュールされていますが、これは営業時間中に実行する必要がある場合もあります。

テーブルには現在 250,000 レコードがあり、1 日あたり約 500 から 3000 レコードずつ増加しています。

なぜそれが急速に断片化されているのかについてのアイデアはありますか?

4

3 に答える 3

3

インデックスの FILL FACTOR を変更して断片化を減らすことができます。

デフォルトの FILL FACTOR 値は 0 です。これは、基本的に 100% の FILL FACTOR として扱われます。つまり、新しいインデックス レコードを挿入するために予約される余分なスペースはありません。これは、インデックス レコードをインデックスの末尾にのみ追加する場合 (ID フィールドなど) には理想的ですが、途中にレコードを挿入する場合には理想的ではありません。

たとえば、フィル ファクタを 80% に設定すると、新しいインデックス レコードを挿入するために、各インデックス ページに 20% の空き領域が予約されます。

于 2009-11-10T10:03:27.960 に答える
1

考え:

  • インデックスを再構築する場合、再編成または再構築しますか? 再構築は 25% 以上の断片化の方が優れています

  • DMO/sqlmaint を使用している場合は、fillfactor 90 に対して「10」と指定する必要があります。

  • ALTER INDEX ALL ON Mytableなど、実際にすべてのインデックスをデフラグしていますか ...

  • 行の 90% 以上でこれらの列を更新しない限り、そのレベルの書き込みで 90% の断片化を実現することはできません...

于 2009-11-10T13:07:41.870 に答える
0

新しい行の数は、そのレベルの断片化を生成することはできませんが、推測だけでなく、主にテーブルのクラスター化インデックスとは何か、さらに情報が必要です。

また、高レベルの断片化を簡単に引き起こす可能性があるため、再インデックスの後にメンテナンスまたは auto_shrink でシュリンクが設定されているかどうかを確認します。

于 2009-11-10T10:06:32.173 に答える