Перестроение индексов

Question

[RedQuark]

В библиотеки Microsoft есть пример пересроения/реорганизации всех индексов по критерию основанном на параметре avg_fragmentation_in_percent > 10.0. Для маленьких таблиц он всегда в некоторых случаях дает 60-80% в зависимости от fillfactor(80-100%).
1) Это (avg_fragmentation_in_percent не понижаеться) связано с дескретностью шага резервирования места на диске для индекса?
2) Как правильно искать деградировавшие индексы (avg_fragmentation_in_percent не всегда отражает проблемы)?
3) Как выбираеться fillfactor (ни каких внятных объеснений кроме субъективной оценки интесинвности изменения таблицы не видел)?

Answer 1

[unfilled]

Вообще, эта штука (перестройка/реорганизиаця индексов) очень сильно переоценена. Пол Рэндал, например, открыто говорит, что трэшхолды (5 и 30% для реорганизации/перестройки) он просто взял из головы, потому что надо было что-то написать.
Ну и вот ещё хорошее свежее видео.
Вообще, по существу:
1. Пока индекс маленький, для его хранения SQL Server использует смешанные экстенты, соответственно, страницы индекса разбросаны по разным экстентам и реорганизация/перестройка никак, по сути, на него и не влияют. С маленькими индексами я вообще не заморачиваюсь.
2. Смотря что понимать под «деградированностью». В принципе, вкупе с page_count и avg_page_space_used_in_percent, avg_fragmentation_in_percent даёт вполне себе понятную картинку.
3. Так и выбирается. Если вы видите, что при вставке постоянно происходят page split'ы, то, возможно, имеет смысл сделать fill factor поменьше. Но при этом стоит помнить, что индекс сразу же раздуется в объёме, соответственно, поиск по нему будет осуществляться более медленно.

Comments

[unfilled]

Если вы видите, что при вставке постоянно происходят page split'ы

точнее, даже не так — «Если вы уверены, что ваши проблемы связанны с постоянно происходящими page split'ами при вставке»