Когда я должен перестроить индексы?

Когда мне следует перестраивать индексы в моей реляционной базе данных (SQL Server)?

Есть ли основания для перестройки индексов на регулярной основе?

Риск быть слишком общим в моем ответе, я скажу, что вы должны регулярно выполнять процесс обслуживания индекса. Тем не менее, ваш процесс обслуживания индекса должен только перестроить / реорганизовать индексы, которые конкретно в этом нуждаются.

В связи с этим возникает вопрос: когда индекс требует перестройки или реорганизации? Роландо хорошо это затронул. Опять же, я рискую быть чрезвычайно широким. Индекс требует обслуживания, когда уровень фрагментации отрицательно влияет на производительность. Этот уровень фрагментации может варьироваться в зависимости от размера и состава индекса.

Говоря о SQL Server, я склонен выбирать размер индекса и уровень фрагментации индекса, после чего я начинаю выполнять обслуживание индекса. Если индекс содержит менее 100 страниц, я не буду выполнять обслуживание.

Если индекс от 10% до 30% фрагментирован, я буду REORGANIZEиндексировать и UPDATEстатистику. Если индекс фрагментирован более чем на 30%, я буду REBUILDиндексировать - нет UPDATE STATISTICS, так как об этом позаботится REBUILD. Помните, однако, что пересборка обновляет только объект статистики, непосредственно связанный с индексом. Другие столбцы статистики необходимо будет поддерживать отдельно.

Этот ответ на самом деле очень далек от того, чтобы сказать: да, вы должны выполнять обычное обслуживание индексов, но только для тех индексов, которые в этом нуждаются.

Когда мне следует перестраивать индексы в моей реляционной базе данных (например, SQL Server)?

Вы должны перестраивать индексы, когда они становятся сильно фрагментированными специальными событиями. Например, вы выполняете большую массовую загрузку данных в индексированную таблицу.

Есть ли основания для перестройки индексов на регулярной основе?

Так что, если ваши индексы становятся фрагментированными из-за регулярной активности? Должны ли вы запланировать регулярные перестройки? Как часто они должны бежать?

Tom Kyte в этой классической теме Ask Tom рекомендует:

Промежуток времени между перестройками индекса должен быть примерно НАВСЕГДА.

...

Не знаю, как это сказать лучше - индекс хочет быть большим и толстым с дополнительным пространством. Он находится в столбце, который вы обновляете - перемещая элемент указателя с места на место в указателе. Однажды в строке есть код «A», на следующий день код «G», затем «Z», «H» и так далее. Таким образом, запись индекса для строки перемещается с места на место в индексе. Для этого ему нужно пространство - будет, если пространства нет, мы разделим блок на две части - и создадим пространство. Сейчас индекс толстеет. Со временем индекс в 2-3 раза больше, чем был при запуске, и «наполовину или более пуст», но это нормально, поскольку вы перемещаете строки. Теперь, когда мы перемещаем ряды, нам больше не нужно разбивать блоки, чтобы освободить место - комната уже доступна.

Затем вы приходите и перестраиваете или удаляете и воссоздаете индекс (что дает тот же эффект - только перестраивание «безопаснее») не имеет шансов потерять индекс и может быть быстрее, так как индекс может быть перестроен с помощью сканирование существующего индекса вместо сканирования таблицы, сортировка и создание нового индекса). Теперь все это прекрасное пространство исчезло. Мы начинаем процесс разделения блоков заново - возвращаем нас туда, откуда мы начали.

Вы не сэкономили места.

Индекс вернется таким, каким он был.

Вы бы просто потратили время на его восстановление, и этот порочный круг повторился.

Логика здесь здравая, но она смещена в сторону профиля с высокой нагрузкой на чтение.

«Толстый» индекс (т. Е. Индекс с большим количеством пробелов) действительно оставляет достаточно места для новых и перемещенных строк, тем самым сокращая разбиение страниц и поддерживая скорость записи. Однако, когда вы читаете из этого толстого индекса, вам придется читать больше страниц, чтобы получить те же данные, потому что вы теперь просматриваете больше пустого пространства. Это замедляет ваше чтение.

Таким образом, в базах данных с большим объемом чтения вы хотите регулярно перестраивать или реорганизовывать свои индексы. (Как часто и при каких условиях? У Matt M уже есть конкретный ответ на этот вопрос.) В базах данных, которые выполняют примерно одинаковые операции чтения и записи, или в базах данных с интенсивной записью, вы, вероятно, наносите ущерб производительности вашей базы данных, перестраивая индексы регулярно.

Большинство людей перестраивают их на регулярной основе, чтобы они никогда не разбирались на фрагменты. Необходимость их восстановления зависит от того, насколько быстро они будут фрагментированы. Некоторые индексы нужно будет часто перестраивать, другие в основном никогда. Посмотрите на сценарий, который SQLFool собрал, который обрабатывает многое для вас.

Как отмечается в принятом ответе от Мэтта М, общее практическое правило заключается в том, что индексы, которые фрагментированы более чем на 30%, должны быть перестроены.

Этот запрос поможет вам определить, сколько у вас индексов, которые фрагментированы более чем на 30% (если они у вас есть, вы должны перестроить их):

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

Когда я должен перестроить индексы?

При фрагментации индекса процент составляет более 30%.

Есть ли основания для перестройки индексов на регулярной основе?

Такого случая не существует, но в целом выполнение обслуживания индекса один раз в неделю в выходные дни является наилучшей практикой для поддержания стабильности среды.

Я бы порекомендовал использовать сценарии обслуживания от Ola Hallengren (лучшие сценарии обслуживания), настроить сценарии в соответствии с вашей средой и запланировать их запуск в выходные.

https://ola.hallengren.com/

Примечание. Пожалуйста, не забудьте обновить статистику после перестроения индексов, потому что перестроение индексов не обновляет всю статистику.

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

Если это не решает проблему или причина, по которой вы это делаете, это просто успокаиваете какую-то метрику, которую вы отслеживаете, потому что это может улучшить ситуацию, тогда все, что вы делаете - это сжигание процессора и ввода-вывода и, возможно, усугубление вашей проблемы.

Существует аргумент, что исправление фрагментации не будет иметь никакого значения для вашего сервера, так стоит ли вообще делать это регулярно?

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

http://brentozar.com/go/defrag