Как избежать неуникального кластерного индекса в тупиках
У меня есть таблица без первичного ключа. Но он имеет неуникальный кластерный индекс на 4 столбца. Мы видим, что этот индекс является частью тупика при обновлении одного из неключевых столбцов в таблице. Как мы можем избежать этого? Лучше создать первичный ключ с 5 столбцами или добавить столбец идентификации? Возможно, нам также потребуется создать некластеризованный индекс для повышения производительности после удаления существующего кластеризованного индекса.
1 ответ
Лучший (до сих пор) ресурс для разрешения тупиковых ситуаций находится здесь: http://blogs.msdn.com/b/bartd/archive/2006/09/09/deadlock-troubleshooting_2c00_-part-1.aspx.
Часть 4 говорит:
Запустите запросы, связанные с тупиком, через помощник по настройке базы данных. Создайте запрос в окне запросов Management Studio, измените контекст базы данных на правильную базу данных, щелкните правой кнопкой мыши текст запроса и выберите "Анализ запроса в DTA". Не пропустите этот шаг; более половины проблем с блокировками, которые мы видим, решаются простым добавлением соответствующего индекса, чтобы один из запросов выполнялся быстрее и с меньшим объемом блокировки. Если DTA рекомендует индексы (там будет написано "Ожидаемое улучшение: %"), создайте их и следите, чтобы убедиться, что тупик сохраняется. Вы можете выбрать "Применить рекомендации" в раскрывающемся меню "Действие", чтобы немедленно создать индекс, или сохранить команды "CREATE INDEX" в виде сценария для их создания во время окна обслуживания. Обязательно настройте каждый из запросов отдельно.
Я знаю, что это не "отвечает" на вопрос "почему", но показывает, что добавление индексов может изменить выполнение таким образом, чтобы уменьшить занимаемую площадь блокировки или ускорить время выполнения, что может значительно снизить вероятность возникновения тупика.