Відповіді:
Загрожуючи занадто загальним у своїй відповіді, я скажу, що вам слід регулярно запускати процес обслуговування індексу. Однак ваш процес обслуговування індексу повинен лише перебудовувати / реорганізувати індекси, які конкретно цього вимагають.
Тут виникає питання: коли індекс потребує перебудови чи реорганізації? Роландо цього приємно торкнувся. Знову я ризикую надзвичайно широким. Індекс вимагає обслуговування, коли рівень фрагментації негативно впливає на продуктивність. Цей рівень фрагментації може змінюватися залежно від розміру та складу індексу.
Говорячи про SQL Server, я схильний вибирати розмір індексу та рівень фрагментації індексу, після чого починаю виконувати обслуговування індексу. Якщо індекс містить менше 100 сторінок, я не виконуватиму обслуговування.
Якщо індекс розрізнений між 10% і 30%, я буду REORGANIZEіндексувати і UPDATEстатистику. Якщо індекс більш ніж 30% фрагментований, я буду REBUILDіндексувати - ні UPDATE STATISTICS, оскільки це подбає про REBUILD. Пам'ятайте, що, хоча відбудова лише оновлює лише об'єкт статистики, безпосередньо пов'язаний з індексом. Іншу статистику стовпців потрібно вести окремо.
Ця відповідь насправді лише довгий шлях: Так, ви повинні робити рутинне обслуговування індексу, але тільки на індекси, які цього потребують.
Коли мені слід відновити індекси в моїй реляційній базі даних (наприклад, SQL Server)?
Вам слід перебудовувати індекси, коли вони сильно роздроблені спеціальними подіями. Наприклад, ви виконуєте велике масове завантаження даних в індексовану таблицю.
Чи є випадки регулярної перебудови індексів?
Що робити, якщо ваші індекси регулярно фрагментуються через регулярну діяльність? Чи слід планувати регулярні перебудови? Як часто вони бігають?
Том Кіт , у цій класичній темі Ask Tom , рекомендує:
Час затримки між перебудовами індексу повинен бути приблизно ЗАВЖДИ.
...
Не знаєте, як сказати це краще - індекс хоче бути великим і жирним з додатковим простором. Він знаходиться в стовпці, який ви оновлюєте - переміщуючи запис індексу з місця на місце в індексі. Одного дня рядок має код "A", наступного дня код - "G", потім "Z", потім "H" і так далі. Тож запис індексу для рядка переміщується з місця на місце в індексі. Оскільки це робиться, йому потрібен простір - ми, якщо місця не буде, розділимо блок на два - і зробимо простір. Зараз індекс товстіє. З часом індекс на 2-3 рази перевищує розмір, коли ви починали, і він "наполовину чи більше порожній", але це нормально, оскільки ви переміщуєте ряди. Тепер, коли ми пересуваємо ряди, нам більше не доведеться ділити блоки, щоб звільнити місце - кімната вже доступна.
Тоді ви збираєтесь і відновлюєте або відмовляєтесь і відтворюєте індекс (які мають однакові ефекти - просто перебудова є "безпечнішою" - не має шансів втратити індекс і може бути швидше, оскільки індекс можна відновити сканування існуючого індексу замість сканування таблиці та сортування та побудова нового індексу). Тепер усього цього приємного простору вже немає. Ми починаємо процес розбиття блоків заново - повертаємо нас туди, де ми почали.
Ви не заощадили місця.
Покажчик повернувся таким, яким він був.
Ви би просто витрачали свій час, щоб відновити його знову, викликаючи повторення цього порочного циклу.
Логіка тут є здоровою, але вона упереджена щодо профілю важкого навантаження.
"Жирний" індекс (тобто той, що має велику кількість прогалин) дійсно залишає достатньо місця для нових та переміщених рядків, тим самим зменшуючи розбиття сторінки та зберігаючи швидкість запису. Однак, коли ви читаєте з цього індексу жиру, вам доведеться прочитати більше сторінок, щоб отримати ті самі дані, тому що ви зараз просіюєте більше порожнього місця. Це сповільнює читання.
Отже, у важких для читання базах даних ви хочете регулярно перебудовувати або реорганізовувати свої індекси. (Як часто і за яких умов? Метт М вже має конкретну відповідь на це питання.) У базах даних, які мають приблизно еквівалентну активність читання і запису, або в базах даних, які важкі для запису, ви, швидше за все, завдаєте шкоди продуктивності вашої бази даних шляхом відновлення індексів. регулярно.
Більшість людей реконструюють їх на регулярній основі, щоб вони ніколи не потрапляли до роздробленості. Коли вам потрібно відновити їх, базується на швидкості їх фрагментації. Деякі індекси потрібно буде перебудовувати часто, інші - ніколи. Ознайомтеся зі сценарієм, який склав 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 (найкращі сценарії обслуговування), налаштувати сценарії відповідно до вашого оточення та запланувати їх запуск на вихідні.
Примітка. Будь ласка, не забудьте оновити статистику після відновлення індексів, оскільки повторна побудова індексів не оновлює всю статистику.
Як і в більшості речей в ІТ, це залежить. Яку проблему ви намагаєтеся вирішити, переробляючи індекси? Чи можете ви показати, що це фактично вирішує проблему? Якщо так, то налаштовуйте номери до тих пір, поки не знайдете найменший обсяг обслуговування, який потрібно зробити, щоб усунути проблему.
Якщо це не вирішує проблему, або причина, по якій ви це робите, - це просто заспокоїти деяку метрику, яку ви відстежуєте, оскільки це може покращити ситуацію, тоді все, що ви робите, - це спалювання процесора та IO і, можливо, погіршує вашу проблему.
Є аргумент, що виправлення фрагментації не матиме ніякого значення для вашого сервера, тож чи варто взагалі регулярно робити це?
https://www.brentozar.com/archive/2017/12/index-maintenance-madness/