Как часто следует перестраивать индексы в нашей базе данных SQL Server?
-
21-09-2019 - |
Вопрос
В настоящее время наша база данных имеет размер 10 ГБ и увеличивается примерно на 3 ГБ в месяц.Часто слышу, что нужно время от времени перестраивать индексы, чтобы улучшить время выполнения запроса.Итак, как часто мне следует перестраивать индексы в данном сценарии?
Решение
Существует общее мнение, что вам следует реорганизовать («дефрагментировать») ваши индексы, как только фрагментация индекса достигнет более 5 (иногда 10%), и вам следует полностью перестроить их, когда она превысит 30% (по крайней мере, это цифры, которые я я слышал, что это защищают во многих местах).
Мишель Аффорд (она же«SQL дурак») имеет сценарий автоматической дефрагментации индекса, который использует именно эти ограничения для принятия решения о реорганизации или перестроении индекса.
Также см Советы Брэда МакГи по восстановлению индексов с некоторыми хорошими мыслями и советами о том, как справиться с перестройкой индекса.
Я использую этот скрипт здесь (не помню, от кого я его получил:большое спасибо!Действительно полезная штука) для отображения фрагментации индекса по всем вашим индексам в данной базе данных:
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 делает это, например, имеет
@minFragmentation
и@rebuildThreshold
параметрыСкажем, собирайте статистику ежедневно, а индексы — по выходным.Каково ваше окно обслуживания?
Индексы следует перестраивать достаточно часто, чтобы деградация индекса не оказала пагубного влияния на производительность.Я понимаю, что это кажется расплывчатым, но все базы данных разные и используются по-разному.Вам нужно только регулярно перестраивать/дефрагментировать индексы, которые требуют операций записи (вставки/обновления) – ваши статические таблицы или таблицы, в основном только для чтения, не будут нуждаться в длительном переиндексировании.
Вам нужно будет использовать dbcc showcontig([Table])
чтобы проверить уровень фрагментации ваших индексов, определить, как часто они фрагментируются и какой уровень фрагментации на самом деле.
Использовать dbcc dbreindex([Table])
чтобы полностью перестроить индексы, когда они становятся слишком фрагментированными (более 20%-30% или около того), но если вы не можете найти достаточно большое окно простоя, а уровень фрагментации относительно низок (1%-25%), вам следует использовать dbcc indexdefrag([Database], [Table], [Index])
дефрагментировать индекс в режиме «онлайн».Также имейте в виду, что вы можете остановить операцию дефрагментации индекса и запустить ее снова позже, не теряя при этом никакой работы.
Поддержание базы данных и ее индексов в «настроенном состоянии» требует некоторого мониторинга, чтобы действительно понять, когда и что переиндексировать.
Учитывая размер вашей базы данных, вы можете легко перестраивать индексы раз в месяц.Но по мере увеличения размера, скажем, примерно до 500 ГБ, вы можете делать это дважды в месяц.