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

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

26
indexing maintenance-plan sql-server sql-server-2005

4 ответов

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

Мишель Аффорд (a.к. 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
37

"когда нужно" и "когда можно"!

например...

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

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

4

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

1

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

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

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

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

1