Por que não recriar índices com contagem de páginas <1000?

Eu uso o script Ola Hallengrens para manutenção do índice. Antes de fazer isso, usei a seguinte consulta para ver quais índices são mais fragmentados:

SELECT dbschemas.[name] as 'Schema',
dbtables.[name] as 'Table',
dbindexes.[name] as 'Index',
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
ORDER BY indexstats.avg_fragmentation_in_percent desc

No meu caso, a avg_fragmentation estava acima de 70% para 15 índices e acima de 30% para 28 índices.

Então, reconstruo todos os índices usando a solução de Ola Hallengren. Quando executei a consulta novamente, este foi o resultado:

Fragmentação acima de 70% para 12 índices, acima de 30% para 15 índices.

Achei que o motivo era o page_countmenor que 1000 para cada um dos índices ainda muito fragmentados. Por exemplo, um dos índices com um page_count de 967 tem uma porcentagem de fragmentação de 98,98% ! Para mim, parece valer a pena reconstruir esse índice! Eu fiz, e depois, a fragmentação foi de 0% . Além disso, um índice com page_count132 passou de 95% para 0%

Então, minha pergunta é: quais os motivos para NÃO reconstruir esses índices? Um motivo pode ser que a reconstrução custa tempo e recursos, mas como os índices são pequenos, isso não significa que custa relativamente poucos recursos e ainda assim seria benéfico reconstruí-lo de qualquer maneira?

Existem várias perguntas relacionadas neste site, mas todas respondem à pergunta por que um índice não desfragmentaria, ou se os índices ainda seriam úteis se fossem pequenos e você não os desfragmentasse, enquanto aqui a instrução diminui a fragmentação, com a questão é: por que não fazer assim mesmo?

As orientações relativas ao número mínimo de páginas são um tanto arbitrárias . Os maiores benefícios da redução da fragmentação são:

1. Pode melhorar o desempenho de leitura antecipada para varreduras de grande alcance; e
2. Pode melhorar a densidade da página (número de linhas por página)

Esses dois fatores são menos importantes para pequenos índices, por definição.

O contra-argumento para reconstruir pequenos índices é essencialmente:

"Por que se preocupar? Você não tem coisas mais importantes com que se preocupar?".

Dito isto, a reconstrução / reorganização não é gratuita. Pode valer a pena evitar o esforço extra e a geração de log em alguns casos (por exemplo, se o log for enviado / copiado em uma WAN por qualquer número de razões possíveis - espelhamento, grupos de disponibilidade, replicação ...). Além disso, a menos que (ou mesmo se, em alguns casos) você esteja reconstruindo online, a reconstrução poderá afetar outros processos simultâneos através do bloqueio. Finalmente, para índices pequenos, a reconstrução pode nem reduzir a fragmentação, devido a alocações de extensões mistas (a menos que você esteja executando com o sinalizador de rastreamento 1118 ativado).

Se você ainda se sente mais feliz ao reconstruir esses pequenos índices e não se importa com as consequências, altere de qualquer maneira o valor do @PageCountLevelparâmetro passado ao procedimento de Ola.

Veja a gravação do PASS TV da apresentação de Paul Randal na fragmentação do índice para obter todos os detalhes.

Talvez você também goste de assistir Brent Ozar falar sobre Por que a fragmentação de índice não importa no SQL Server.