Некластеризованный индекс включает столбец, вызывает высокую фрагментацию

Question

У меня есть некластеризованный индекс в Azure SQL Server следующим образом:

CREATE NONCLUSTERED INDEX [IX_index_xx] 
ON [dbo].[ActiveDay] ([user_id] ASC, [enterprise_id] ASC)
INCLUDE ([dateTime])  
WITH (STATISTICS_NORECOMPUTE = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]

Когда приложение работает, оно может вводить новые строки в эту таблицу или обновлять столбец «dateTime», когда пользователь выполняет некоторые операции, такие как вход в систему. В этой таблице нет других тяжелых операций. У меня есть около 135 000 строк в таблице. Я перестроил вышеупомянутый индекс, но через 1 день он снова фрагментируется с 60% с количеством страниц около 1370. Почему он становится сильно фрагментированным в течение 1 дня? Я действительно не понимаю причину.

Answer 1

Почему он становится сильно фрагментированным в течение 1 дня?

Строки в этом индексе отсортированы по (user_id, enterprise_id). Поэтому, когда вы вставляете новую строку в таблицу, она может идти в end кластеризованного индекса, но она должна быть вставлена ​​в middle этого некластеризованного индекса. Если целевая страница заполнена, она должна быть разделена, и для этой базы данных будет запущена не полная страница.

Чередование экстентов из разных объектов и чередование страниц из разных частей порядка сортировки индекса являются обоими типами фрагментации. Этот вид фрагментации некластеризованного индекса является нормальным и, как правило, незначительной проблемой, особенно если ваша база данных хранится на твердотельных накопителях, как и все базы данных SQL Azure.

После перестроения индекса все конечные страницы в индексе заполнены на 100%, и фрагментация в основном устранена. Но когда вы вставляете в таблицу новые строки, фрагментация естественным образом возвращается. Сразу после перестройки любая вставка потребует разбиения страницы и приведет к некоторой фрагментации. Если вы действительно хотите перестроить индекс, вы можете установить коэффициент заполнения 80% или около того, чтобы предотвратить переполнение страниц после перестроения индекса.