毎日99％のインデックスの断片化を防ぐ方法

1日2回挿入される100.000プレーヤー用のハイスコアテーブルがあり、プレーヤーごとに1つのレコードがあります。1日の終わりに、そのテーブルのインデックスのインデックスの断片化は99％です。設定を微調整してこれを防ぐ方法はありますか？

CREATE TABLE HighScore(
    [id] [int] IDENTITY(1,1) NOT NULL,
    [user] [int] NULL,
    [player] [int] NULL,
    [round] [tinyint] NULL,
    [group] [int] NULL,
    [rank] [int] NULL,
    [delta] [int] NULL,
    [roundpoints] [int] NULL,
    [totalpoints] [int] NULL,
PRIMARY KEY CLUSTERED 
(
    [id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 80) ON [PRIMARY]
) ON [PRIMARY]


CREATE NONCLUSTERED INDEX [HighScore_RoundGroup_Nidx] ON .[HighScore] 
(
    [round] ASC,
    [group] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 80) ON [PRIMARY]
GO

sql-server-2008 index fragmentation

— オルレ
ソース

ばかげた質問ですが、すべての根拠をカバーするために-あなたは毎日再構築/再編成していますか？

— JHFB 2012年

TABLE DDLがなければ、誰もが推測するでしょう。GUIDを主キーとして使用していますか？

— SQL学習者

現在、毎日再構築していますが、データがどのように進化するかをかなりよく予測できるので、これが毎日発生するのを防ぐことができるかどうか疑問に思っています。

— olle

断片化レベルをどのように決定していますか？クラスタ化インデックスでは、論理的な断片化はそれほど期待されません。いくつかの内部の断片化は、しかし、FILLFACTOR = 80そこには必要ありません。スペースを浪費するだけです。すべての列は固定長であるため、更新時に行を拡張したり、テーブルの中央で挿入を行ったりすることはできません。他のインデックスについても、99％は予想外に高いようです。各インデックスには何ページありますか？

— マーティン・スミス、

毎日再構築した後の99％は実際にうまくいくでしょう。sys.dm_db_index_physical_stats出力を表示できますか？

— マーティン・スミス

私はもっと高いFILLFACTOR設定HighScore_RoundGroup_Nidx（例えば50か40）を試すべきだと思います。フラグメント化してはならないFILLFACTORため、0または100に設定できます。PRIMARY KEYそれでもフラグメント化しない場合FILLFACTORは、新しく割り当てられたページが他の新しく割り当てられたページとインターリーブするため、役に立ちません。これはよく知られているSQL Serverの問題です。このインデックスを独自のファイルグループに移動すると、この問題を回避できます。

— usr
ソース

多分あなたはあなたが再構築していると思いますが、インデックスが十分に大きくないのでインデックスは再構築されません。

この質問を見てください。なぜインデックスの再構築はインデックスの断片化を減らしませんか？

再構築後に断片化を確認しましたか？実際に最適化されていますか？

— トムV-topanswers.xyzを試す
ソース