Como evitar a fragmentação diária do índice de 99%

Eu tenho uma tabela de recordes para 100.000 jogadores que está sendo inserida duas vezes ao dia com um registro por jogador. No final do dia, a fragmentação do índice para os índices nessa tabela é de 99%. Existe uma maneira de evitar isso ajustando as configurações?

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

— olle
fonte

Pergunta boba, mas para cobrir todas as bases - você está reconstruindo / reorganizando todos os dias?

— JHFB

sem TABLE DDL, qualquer pessoa que postar vai adivinhar. Você está usando o GUID como chave primária?

— SQL Learner

Estou reconstruindo todos os dias agora, mas me pergunto se posso impedir que isso aconteça todos os dias, pois posso antecipar muito bem como os dados evoluem.

— Olle

Como você está determinando o nível de fragmentação? Eu não esperaria muita fragmentação lógica para o índice clusterizado. Alguma fragmentação interna, porém, você não precisa de FILLFACTOR = 80lá. Vai apenas desperdiçar espaço. Todas as colunas têm comprimento fixo, portanto, uma linha não pode expandir a atualização e as inserções não podem acontecer no meio da tabela. 99% parece inesperadamente alto para o outro índice também. Quantas páginas existem em cada índice?

— Martin Smith

99% após a reconstrução a cada dia seria realmente um pouco, você pode mostrar sua sys.dm_db_index_physical_statssaída?

— Martin Smith

Eu acho que você deve tentar FILLFACTORconfigurações mais altas HighScore_RoundGroup_Nidx(por exemplo, 50 ou 40). Você pode definir FILLFACTOR0 ou 100 para o PRIMARY KEYarquivo porque ele não deve fragmentar. Se isso ocorrer, FILLFACTORnão ajuda porque o motivo é que as páginas recém-alocadas se intercalam com outras páginas alocadas recentemente. Esse é um problema conhecido do SQL Server. Você pode mover esse índice para seu próprio grupo de arquivos, o que interromperia esse problema.

— usr
fonte

Talvez você pense que está reconstruindo, mas o índice não é reconstruído porque o índice não é grande o suficiente.

Dê uma olhada nesta pergunta Por que o índice REBUILD não reduz a fragmentação do índice?

Você verificou a fragmentação após a reconstrução? É realmente desfragmentado.

— Tom V - tente topanswers.xyz
fonte