Индексы перестраиваются для удаления фрагментации. Тысяча и одна статья и сообщения в блоге о природе фрагментации индекса, но @BrentOzar недавно опубликовал особенно краткое объяснение в статье « Перестаньте беспокоиться о фрагментации SQL Server» .
Давайте сделаем шаг назад на секунду и представим, что ваша база данных - это телефонная книга, организованная по фамилии, имени.
Когда люди переезжают в ваш город, мы должны добавить их в телефонную книгу. В идеале на каждой странице должно быть свободное место, и мы определяем это с помощью коэффициента заполнения. Когда SQL Server перестраивает индексы, он использует коэффициент заполнения, чтобы решить, сколько свободного места оставить на каждой странице. Если свободного места недостаточно, SQL Server должен выполнить некоторую перестановку, но он не может точно вставить новую страницу в середину телефонной книги. Книга уже связана. Нам придется добавить больше пустых страниц в конец.
Проблема № 1 - Внутренняя фрагментация: у нас есть недавно добавленная страница, на которой почти ничего нет. Проблема № 2 - Внешняя фрагментация: страницы телефонной книги вышли из строя.
Недавняя статья Брента предлагает обновленный взгляд на одну из его предыдущих серий « Выводы фрагментации индекса» . В более старой статье приводятся статистические данные гораздо более ранних исследований о разрушительном влиянии фрагментации, а в более поздней статье рассматривается возможность снижения значительного процента снижения производительности за счет обеспечения полного кэширования вашей базы данных.
Ram сейчас настолько комично дешев, что это, пожалуй, самое дешевое, простое решение с минимальным риском для сильно фрагментированной базы данных. Особенно, если структура базы данных такова, что она, естественно, станет фрагментированной, несмотря на усилия по обслуживанию.
