#sql-server #indexing #azure-sql-database
#sql-server #индексирование #azure-sql-database
Вопрос:
У меня есть некластеризованный индекс в 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 дня? Я действительно не понимаю причины.
Ответ №1:
Почему он становится сильно фрагментированным в течение 1 дня?
Строки в этом индексе отсортированы по (user_id,enterprise_id). Поэтому, когда вы вставляете новую строку в таблицу, она может находиться в конце кластеризованного индекса, но она должна быть вставлена в середину этого некластеризованного индекса. Если целевая страница заполнена, ее необходимо разделить, и новая страница будет запущена в неполном экстенте для этой базы данных.
Чередование экстентов из разных объектов и чередование страниц из разных частей порядка сортировки индекса — оба типа фрагментации. Такого рода фрагментация некластеризованного индекса является нормальной и обычно не представляет существенной проблемы, особенно если ваша база данных хранится на SSD-накопителях, как и все базы данных SQL Azure.
После перестройки индекса все конечные страницы в индексе заполнены на 100%, и фрагментация в основном устранена. Но по мере вставки новых строк в таблицу фрагментация, естественно, вернется. Сразу после перестройки любая вставка потребует разделения страницы и приведет к некоторой фрагментации. Если вы действительно хотите перестроить индекс, вы можете установить коэффициент заполнения 80% или около того, чтобы предотвратить шквал разбиений страниц после перестройки индекса.
Комментарии:
1. Привет, Дэвид, спасибо за информацию. У меня всегда было впечатление, что если фрагментация некоторых кластеризованных индексов составляет около 97%, то это действительно замедляет некоторые запросы. У меня были ситуации, когда возврат некоторых запросов занимает около 6 минут, и как только я перестраиваю эти некластеризованные индексы, они возвращаются примерно за 3 секунды. Итак, если я не могу полностью полагаться на этот процент фрагментации, как я могу использовать эту информацию о фрагментации в некластеризованных индексах?
2. Перестройка индекса также обновляет статистику, и это может повлиять на выбранный план запроса. В базе данных SQL Azure безопасно игнорировать автоматическую настройку и полагаться на нее, по крайней мере, на начальном этапе. learn.microsoft.com/en-us/azure/sql-database /…