¿Por qué no reconstruir índices con un recuento de páginas <1000?

Utilizo el script Ola Hallengrens para el mantenimiento del índice. Antes de hacerlo, utilicé la siguiente consulta para ver qué índices están más 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

En mi caso, la fragmentación promedio fue superior al 70% para 15 índices y superior al 30% para 28 índices.

Entonces, reconstruyo cada índice usando la solución de Ola Hallengren. Cuando volví a ejecutar la consulta, este fue el resultado:

Fragmentación superior al 70% para 12 índices, superior al 30% para 15 índices.

Supuse que la razón se debía a page_countque era inferior a 1000 para cada uno de los índices que todavía estaban muy fragmentados. ¡Por ejemplo, uno de los índices con un page_count 967 tiene un porcentaje de fragmentación del 98,98% ! ¡Para mí, parece que vale la pena reconstruir ese índice! Lo hice, y luego, la fragmentación fue del 0% . Además, un índice con un page_count132 pasó del 95% al 0%

Entonces, mi pregunta es, ¿qué razones habría para NO reconstruir esos índices? Una razón podría ser que la reconstrucción cuesta tiempo y recursos, pero debido a que los índices son pequeños, ¿no significa esto que cuesta relativamente pocos recursos y que de todos modos sería beneficioso reconstruirlo?

Hay varias preguntas relacionadas en este sitio, pero todas responden a la pregunta de por qué un índice no se desfragmentaría, o si los índices siguen siendo útiles si son pequeños y no los desfragmenta, mientras que aquí la declaración SÍ disminuye la fragmentación, con la pregunta es, ¿por qué no hacerlo de todos modos?

La orientación sobre el número mínimo de páginas es algo arbitraria . Los mayores beneficios de reducir la fragmentación son:

1. Puede mejorar el rendimiento de lectura anticipada para escaneos de gran alcance; y
2. Puede mejorar la densidad de la página (número de filas por página)

Ambos factores son menos importantes para índices pequeños, por definición.

El contraargumento para reconstruir índices pequeños es esencialmente:

"¿Por qué molestarse? ¿No tienes cosas más importantes de las que preocuparte?".

Dicho esto, la reconstrucción / reorganización no es gratuita. Puede valer la pena evitar el esfuerzo adicional y la generación de registros en algunos casos (por ejemplo, si el registro se envía / copia a través de una WAN por cualquier número de razones posibles: duplicación, grupos de disponibilidad, replicación ...). Además, a menos que (o incluso, en algunos casos) esté reconstruyendo en línea, la reconstrucción puede afectar otros procesos concurrentes a través del bloqueo. Finalmente, para índices pequeños, es posible que la reconstrucción ni siquiera reduzca la fragmentación de todos modos, debido a las asignaciones de extensiones mixtas (a menos que esté ejecutando con el indicador de seguimiento 1118 habilitado).

Si aún se siente más feliz reconstruyendo estos pequeños índices, y no le importan las consecuencias, cambie el valor del @PageCountLevelparámetro pasado al procedimiento de Ola.

Vea la grabación de PASS TV de la presentación de Paul Randal en Index Fragmentation para todos los detalles.

También le gustaría ver a Brent Ozar hablar sobre por qué la fragmentación del índice no importa en SQL Server.