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

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

4 ответа

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

Michelle Ufford (aka "SQL Fool" ) имеет автоматическую индексацию дефрагментации script, которая использует те точные пределы для принятия решения о реорганизации или перестроить индекс.

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

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

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


"Когда вам нужно" и "Когда вы можете"!

Например...

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

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


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


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

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

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

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

licensed under cc by-sa 3.0 with attribution.