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