Как часто следует перестраивать индексы в нашей базе данных SQL Server?

Question

В настоящее время наша база данных имеет размер 10 ГБ и увеличивается примерно на 3 ГБ в месяц. Часто слышу, что время от времени нужно перестраивать индексы, чтобы улучшить время выполнения запроса. Так как часто я должен перестраивать индексы в данном сценарии?

Answer 1

Существует общее мнение, что вы должны реорганизовать («дефрагментировать») свои индексы, как только фрагментация индекса достигнет более 5 (иногда 10%), и вам следует полностью перестроить их, когда она превысит 30% (по крайней мере, это цифры, которые я слышал, пропагандируются во многих местах).

Мишель Аффорд (a.k.a. «SQL Fool») имеет сценарий автоматической дефрагментации индекса , который использует эти точные ограничения для принятия решения о том, когда реорганизовать или перестроить индекс.

Также см. Советы Брэда МакГи по перестройке индексов с некоторыми полезными мыслями и советами о том, как бороться с перестройкой индексов.

---

Я использую этот сценарий здесь (не помню, когда я его получил - кто бы это ни был: большое спасибо! Очень полезные вещи), чтобы отобразить фрагментацию индекса по всем вашим индексам в данной базе данных:

SELECT 
    t.NAME 'Table name',
    i.NAME 'Index name',
    ips.index_type_desc,
    ips.alloc_unit_type_desc,
    ips.index_depth,
    ips.index_level,
    ips.avg_fragmentation_in_percent,
    ips.fragment_count,
    ips.avg_fragment_size_in_pages,
    ips.page_count,
    ips.avg_page_space_used_in_percent,
    ips.record_count,
    ips.ghost_record_count,
    ips.Version_ghost_record_count,
    ips.min_record_size_in_bytes,
    ips.max_record_size_in_bytes,
    ips.avg_record_size_in_bytes,
    ips.forwarded_record_count
FROM 
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') ips
INNER JOIN  
    sys.tables t ON ips.OBJECT_ID = t.Object_ID
INNER JOIN  
    sys.indexes i ON ips.index_id = i.index_id AND ips.OBJECT_ID = i.object_id
WHERE
    AVG_FRAGMENTATION_IN_PERCENT > 0.0
ORDER BY
    AVG_FRAGMENTATION_IN_PERCENT, fragment_count

Answer 2

«Когда нужно» и «Когда можно»!

Например ...

• Сначала проверьте на фрагментацию и решите, ничего не делать, перестроить или перестроить. Сценарий SQL Fool делает это , например, имеет @minFragmentation и @rebuildThreshold параметры

• Делайте статистику ежедневно, скажем, но индексируйте в выходные дни. Каково ваше окно обслуживания?

Answer 3

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

Вам нужно будет использовать dbcc showcontig([Table]), чтобы проверить уровень фрагментации ваших индексов, определить, как часто они становятся фрагментированными и каков уровень фрагментации на самом деле.

Используйте dbcc dbreindex([Table]), чтобы полностью перестроить индексы, когда они становятся слишком фрагментированными (выше 20% -30% или около того), но если вы не можете найти достаточно большое окно простоя, а уровень фрагментации относительно низок (1% -25% ), вы должны использовать dbcc indexdefrag([Database], [Table], [Index]) для дефрагментации индекса в режиме онлайн. Также имейте в виду, что вы можете остановить операцию дефрагментации индекса и запустить ее позже, не теряя никакой работы.

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

Answer 4

Учитывая размер вашей базы данных, вы можете легко перестраивать индексы один раз в месяц. Но по мере увеличения размера, скажем, до 500 ГБ, вы можете делать это дважды в месяц.