Оставляя в стороне все несвязанные технические аспекты; Фрагментация в контексте базы данных - это упорядоченные данные, хранящиеся неупорядоченным образом. Это приводит к нежелательному снижению производительности и замедлению работы базы данных.
Допустим, у вас есть таблица с сотрудниками. Индекс содержит отсортированные данные для доступа сотрудников по их идентификационному номеру. Индекс содержит данные, хранящиеся в последовательности. Из соображений простоты у нас есть таблица, содержащая четырех сотрудников:
1 Anne
3 Charly
4 James
5 William
. Ядро базы данных хранит несколько сотрудников на странице. Обычно это сортированный ковш фиксированного размера. Итак, давайте разместим сотрудников на странице. Давайте предположим, что мы можем разместить только двух сотрудников на странице. В итоге мы получили бы:
[ Page 1, next page is page 2, there is no previous page ]
1 Anne
2 Charly
[ Page 2, there is no next page, but there is a previous page 1 ]
4 James
5 William
Теперь возникает проблема, когда мы хотим добавить Берта с идентификационным номером 3. Он не помещается ни на одной странице. Не в конце страницы 1 или в начале страницы 2. Нам нужно создать новую страницу для Берта и исправить ссылки на (предыдущую и следующую) страницы так, чтобы они все еще были упорядочены.
[ Page 1, next page is page 3, there is no previous page ]
1 Anne
2 Charly
[ Page 2, there is no next page, but there is a previous page 3 ]
4 James
5 William
[ Page 3, next page is page 2, previous page 1 ]
3 Bert
Обратите внимание, что страница 3 находится в конце списка. Механизм базы данных может по-прежнему запускаться со страницы 1 и go по страницам упорядоченным образом; а именно, переходя к следующей странице 3, а затем к следующей странице 2. Однако это не оптимально. Движок должен перепрыгивать назад и вперед, чтобы найти свои данные, а не просто переходить от страницы 1 к последней странице. Это именно то, что фрагментация индекса.
Мы можем дефрагментировать индекс, снова сортируя (и перестраивая) страницы. Я избавлю вас от конкретных c шагов, но в результате этого страницы упорядочены и все содержащиеся в них данные также упорядочены.
[ Page 1, next page is page 2, there is no previous page ]
1 Anne
2 Charly
[ Page 2, next page is page 3, previous page 1 ]
3 Bert
4 James
[ Page 3, there is no next page, previous page 2 ]
5 William
Вы можете спросить, почему бы не сделать это прямо сейчас? Всегда есть компромисс. Изменение наименьшего количества данных (в данном случае страниц) беспокоит наименьшее количество других пользователей (в этом случае другие запросы или изменения в базе данных). В сценарии, где новая страница размещается в конце, нам нужно изменить только несколько страниц. Если бы мы обновили указатель, чтобы он был полностью упорядочен, для этого потребовалось бы изменить большинство страниц, если не все. При изменении страницы другие изменения на той же странице (или хуже) должны ждать принятия предыдущего изменения.