Таблица не имеет кластеризованного индекса. Что произойдет, если я перестрою индексы?
У нас есть приложение поставщика, которое имеет базу данных SQL Server 2005. Во время ввода данных приложение записывает данные в таблицу, в которой нет кластерных индексов. Однако в таблице есть несколько индексов.
Я использовал мастер плана обслуживания для перестройки индексов в этой таблице.
Во время тестирования производительности мы начали сталкиваться с проблемами взаимоблокировки. График взаимоблокировки показывает, что именно эта таблица без кластеризованного индекса является той, за которую борются.
Затем я использовал мастер плана обслуживания для перестроения индексов с помощью fillfactor 80. Теперь никаких тупиков не было. Любые идеи, почему этот fillfactor будет иметь значение?
2 ответа
Есть несколько возможностей, о которых я могу подумать.
@ Крис избил меня до конца первой частью того, что я собирался сказать, поэтому я не буду повторять это.
Вторая и менее вероятная IMO возможность состоит в том, что перестройка индекса также обновляет статистику, и SQL-сервер теперь использует разные планы выполнения, позволяющие избежать тупиковой ситуации.
Единственный способ действительно сказать, это тщательно изучить график тупиков и до и после QEP. Что может быть невозможно сейчас, если проблема была "исправлена".
Наконец, я сомневаюсь, что это будет навсегда.
Вам не нужен кластерный индекс, хотя это, как правило, хорошая идея. Если, конечно, первичным ключом является GUID или записи в таблице проходят через высокий процент удалений / вставок. Я думаю о чисто временных таблицах хранения.
Скорее всего, индексы, которые использовались взаимоблокирующими запросами, были сильно фрагментированы, поэтому перестройка индекса вызвала проблему.
Вы можете профилировать эти запросы, чтобы увидеть, будут ли полезны другие индексы.