У меня есть хранимая процедура, которая выполняется для любого изменения объектов в таблице A (Хранимая процедура запускается триггером после обновления).Хранимая процедура, в свою очередь, обновляет таблицу B, которая имеет ссылку внешнего ключа на таблицу A (и другую таблицу, скажем, Table C) и два индекса.
Теперь в этой хранимой процедуре передан параметр, который является уникальным идентификатором таблицы A, поэтому любой доступ к основной таблице A очень специфичен для каждой строки, т. Е. Всегда влияет только на одну строку.
Одна и та же настройка применяется для нескольких проектов в нашей системе, но план выполнения, созданный для одного конкретного проекта, отличается от других, и я сузился до источника проблемы.План выполнения точно такой же до фактической вставки таблицы (таблица B), но отличается от этого для утверждений индекса и внешнего ключа.
Вот снимок экрана "хорошего плана", где утверждения внешнего ключа выполняются с использованием поиска по кластерному индексу.
Хороший план
Вот план выполнения для этого конкретного проекта, где мы видим много взаимоблокировок, и это потому, что есть сканирование кластерного индекса для этих утверждений внешнего ключа.Когда я удаляю внешний ключ, проблема исчезает.Почему здесь сканирование?У нас есть индексы по внешним ключам.Кроме того, почему вкладки некластеризованного индекса расширены в этом плане?И что делает оператор последовательности?Я попытался RECOMPILE, и он сгенерировал тот же план со сканированием для обновления внешнего ключа.
Плохой план