Почему бы не перестроить индексы с количеством страниц <1000?

Я использую скрипт Ola Hallengrens для поддержки индекса. Прежде чем сделать это, я использовал следующий запрос, чтобы увидеть, какие индексы наиболее фрагментированы:

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

В моем случае avg_fragmentation было более 70% для 15 индексов и более 30% для 28 индексов.

Итак, я перестраиваю каждый индекс, используя решение Олы Хелленгрен. Когда я снова запустил запрос, это был результат:

Фрагментация более 70% для 12 индексов, более 30% для 15 индексов.

Я полагал, что причина была в том page_count, что было ниже 1000 для каждого из индексов, которые все еще были очень фрагментированы. Например, один из индексов с page_count 967 имеет процент фрагментации 98,98% ! Мне кажется, стоит пересмотреть этот индекс! Я сделал, и после этого фрагментация составила 0% . Кроме того, индекс с page_count132 изменился с 95% до 0%

Итак, мой вопрос: по каким причинам НЕ нужно перестраивать эти индексы? Одна из причин может заключаться в том, что восстановление требует затрат времени и ресурсов, но поскольку индексы невелики, не означает ли это, что это стоит относительно небольшого количества ресурсов, и все равно было бы полезно восстановить его в любом случае?

На этом сайте есть несколько связанных вопросов, но все они отвечают на вопрос, почему индекс не будет дефрагментировать, или если индексы все еще полезны, если они маленькие, и вы не дефрагментируете их, тогда как здесь утверждение ДЕЛАЕТ уменьшить фрагментацию с вопрос в том, почему бы не сделать это в любом случае?

Руководство относительно минимального количества страниц несколько произвольно . Самые большие преимущества уменьшения фрагментации:

1. Это может улучшить производительность опережающего чтения для сканирования большого диапазона; и
2. Это может улучшить плотность страницы (количество строк на странице)

Оба эти фактора по определению менее важны для небольших индексов.

Контр-аргумент для перестройки небольших индексов по существу:

«Зачем беспокоиться? Тебе не о чем беспокоиться?».

Тем не менее, восстановление / реорганизация не является бесплатным. В некоторых случаях может быть целесообразно избежать дополнительных усилий и создания журнала (например, если журнал отправляется / копируется по глобальной сети по любому количеству возможных причин - зеркалирование, группы доступности, репликация ...). Кроме того, если (или даже если, в некоторых случаях) вы не перестраиваете онлайн, перестройка может повлиять на другие параллельные процессы через блокировку. Наконец, для небольших индексов перестройка может даже не уменьшить фрагментацию в любом случае из-за выделений из смешанных экстентов (если только вы не используете флаг трассировки 1118 ).

Если вы все еще чувствуете себя счастливее, перестраивая эти маленькие индексы, и не обращаете внимания на последствия, то непременно измените значение @PageCountLevelпараметра, переданного в процедуру Олы.

Посмотрите PASS TV запись презентации Пола Рэндала по фрагментации индекса для всех деталей.

Вы также можете посмотреть, как Брент Озар говорит о том, почему фрагментация индекса не имеет значения в SQL Server.