Quando devo reconstruir índices?

Quando devo reconstruir os índices no meu banco de dados relacional (SQL Server)?

Existe um caso de reconstrução de índices regularmente?

Correndo o risco de ser muito geral na minha resposta, direi que você deve executar um processo de manutenção de índice regularmente. No entanto, seu processo de manutenção de índice deve reconstruir / reorganizar apenas os índices que exigem especificamente.

Isso apresenta a pergunta: quando um índice precisa ser reconstruído ou reorganizado? Rolando tocou nisto muito bem. Mais uma vez, arrisco-me a ser extremamente amplo. Um índice requer manutenção quando o nível de fragmentação afeta adversamente o desempenho. Esse nível de fragmentação pode variar com base no tamanho e na composição do índice.

Falando no SQL Server, costumo escolher um tamanho de índice e um nível de fragmentação no momento em que começo a executar a manutenção do índice. Se um índice contiver menos de 100 páginas, não executarei manutenção.

Se um índice estiver entre 10% e 30% fragmentado, eu irei REORGANIZEao índice e UPDATEàs estatísticas. Se um índice estiver fragmentado em mais de 30%, eu REBUILDo indexarei - sem UPDATE STATISTICS, pois isso é resolvido pelo REBUILD. Lembre-se, porém, que uma reconstrução atualiza apenas o objeto de estatísticas diretamente associado ao índice. Outras estatísticas da coluna precisarão ser mantidas separadamente.

Esta resposta é realmente apenas um longo caminho a dizer: Sim, você deve fazer a manutenção de rotina de índices, mas apenas nos índices que precisam.

Quando devo reconstruir os índices no meu banco de dados relacional (por exemplo, SQL Server)?

Você deve recriar índices quando eles se tornarem altamente fragmentados por eventos especiais. Por exemplo, você executa um carregamento grande e em massa de dados em uma tabela indexada.

Existe um caso de reconstrução de índices regularmente?

E se seus índices estiverem se fragmentando regularmente devido a atividades regulares? Você deve agendar reconstruções regulares? Quantas vezes eles devem correr?

Tom Kyte , neste tópico clássico do Ask Tom , recomenda:

O intervalo de tempo entre as recriações do índice deve ser aproximadamente FOREVER.

...

Não sei como dizer melhor - o índice quer ser grande e gordo com espaço extra. Está em uma coluna que você atualiza - movendo a entrada do índice de um lugar para outro no índice. Um dia a linha tem um código "A", no dia seguinte o código é "G", depois "Z", depois "H" e assim por diante. Portanto, a entrada do índice para a linha se move de um lugar para outro no índice. Ao fazer isso, ele precisa de espaço - será, se o espaço não estiver lá, dividimos o bloco em dois - e criamos espaço. Agora o índice está engordando. Com o tempo, o índice é 2-3 vezes maior do que era quando você iniciou e está "meio ou mais vazio". Mas tudo bem desde que você move as linhas. Agora, quando movemos as linhas, não precisamos mais dividir os blocos para liberar espaço - o quarto já está disponível.

Então você vem e reconstrói ou elimina e recria o índice (que tem os mesmos efeitos - apenas a reconstrução é "mais segura" - não tem chance de perder o índice e pode ser mais rápido, pois o índice pode ser reconstruído por varredura do índice existente em vez de varrer a tabela e classificar e criar um novo índice). Agora, todo esse espaço agradável se foi. Começamos o processo de dividir os blocos novamente - voltando ao ponto em que começamos.

Você não economizou espaço.

O índice está de volta do jeito que era.

Você estaria perdendo seu tempo para reconstruí-lo novamente, fazendo com que esse ciclo vicioso se repetisse.

A lógica aqui é sólida, mas é enviesada em relação a um perfil de carga de leitura pesada.

Um índice "gordo" (ou seja, um com muitas lacunas) realmente mantém uma boa quantidade de espaço para linhas novas e movidas, reduzindo assim as divisões de página e mantendo suas gravações rápidas. No entanto, ao ler esse índice de gordura, você terá que ler mais páginas para obter os mesmos dados, porque agora está examinando mais espaço vazio. Isso atrasa suas leituras.

Portanto, em bancos de dados com muita leitura, você deseja recriar ou reorganizar regularmente seus índices. (Com que frequência e sob quais condições? Matt M já tem uma resposta concreta para esta pergunta.) Nos bancos de dados que apresentam atividades de leitura e gravação aproximadamente equivalentes, ou em bancos de dados com muita gravação, é provável que você prejudique o desempenho do banco de dados reconstruindo índices regularmente.

A maioria das pessoas os reconstrói regularmente para que nunca se fragmentem. Quando você precisa reconstruí-los, baseia-se na rapidez com que eles são fragmentados. Alguns índices precisarão ser reconstruídos com frequência, outros basicamente nunca. Confira o script que o SQLFool montou, que lida com muitas coisas para descobrir isso para você.

Conforme observado na resposta aceita de Matt M, uma regra geral comum é que índices com mais de 30% de fragmentação devem ser reconstruídos.

Esta consulta o ajudará a encontrar quantos índices você possui mais de 30% fragmentados (quando você tiver alguns, deverá reconstruí-los):

SELECT DB_NAME() AS DBName,
       OBJECT_NAME(ind.object_id) AS TableName,
       ind.name AS IndexName,
       indexstats.index_type_desc AS IndexType,
       indexstats.avg_fragmentation_in_percent,
       indexstats.fragment_count,
       indexstats.avg_fragment_size_in_pages,
       SUM(p.rows) AS Rows 
  FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
         INNER JOIN sys.indexes AS ind ON (    ind.object_id = indexstats.object_id
                                           AND ind.index_id = indexstats.index_id)
         INNER JOIN sys.partitions AS p ON (    ind.object_id = p.object_id
                                            AND ind.index_id = p.index_id)
 WHERE indexstats.avg_fragmentation_in_percent > 30
 GROUP BY
       OBJECT_NAME(ind.object_id),
       ind.name,
       indexstats.index_type_desc,
       indexstats.avg_fragmentation_in_percent,
       indexstats.fragment_count,
       indexstats.avg_fragment_size_in_pages 
 ORDER BY indexstats.avg_fragmentation_in_percent DESC

Quando devo reconstruir índices?

Quando a porcentagem de fragmentação do índice for superior a 30%.

Existe um caso de reconstrução de índices regularmente?

Não existe esse caso, mas, em geral, fazer a manutenção do índice uma vez por semana, no fim de semana, é a melhor prática para manter o ambiente estável.

Eu recomendaria usar scripts de manutenção do Ola Hallengren (melhores scripts de manutenção), personalizar os scripts com base no seu ambiente e agendá-los para execução no fim de semana.

https://ola.hallengren.com/

Nota: Não esqueça de atualizar as estatísticas após a reconstrução de índices, porque a reconstrução de índices não atualiza todas as estatísticas.

Como na maioria das coisas em TI, isso depende. Que problema você está tentando corrigir ao reconstruir índices? Você pode mostrar que ele realmente resolve o problema? Nesse caso, ajuste os números até encontrar a menor quantidade de manutenção necessária para corrigir o problema.

Se isso não resolver o problema, ou o motivo pelo qual você está fazendo isso, é apenas para apaziguar algumas métricas que você monitora porque elas podem melhorar as coisas, tudo o que você está fazendo é gravar a CPU e o IO e, possivelmente, piorar o problema.

Há um argumento de que a correção da fragmentação não fará diferença para o servidor, então vale a pena fazer isso regularmente?

https://www.brentozar.com/archive/2017/12/index-maintenance-madness/

http://brentozar.com/go/defrag