SQL Server - тупик в кластерном индексе

Question

у меня есть таблица A с кластеризованным индексом по первичному ключу и некластеризованным индексом по второму столбцу (act_id) (внешний ключ к таблице B)

Два оператора обновления генерируют следующую тупиковую ситуацию: Deadlock 1

Этот тупик, по-видимому, не является тупиком блокировки поиска закладок, поскольку он имеет тот же индекс и тот же объект.Включение ПК в некластеризованный индекс не принесло никакого успеха.Я понял, что objid - это не запись, а диапазон в индексе.

Запросы (например, обновление набора act_id = 1, где act_id = 2), приводящие к этому тупику, имеют следующее выполнениеплан: план выполнения

Иногда тот же тупик находится на другой таблице только с одним кластеризованным индексом: Тот же тупик на другой таблице

Есть кто-нибудьИдея, как этого тупика можно избежать?

Answer 1

Спасибо за ваши ответы.Я нарисовал картинку, чтобы сделать ее более понятной:

У нас есть задачи, в которых есть одно действие.Каждое действие может иметь несколько параметров.Наше приложение состоит из нескольких развертываний.Каждое развертывание может загружать эти задачи.В примере у меня есть три развертывания.2 аддона и один базовый модуль.2 дополнения ждут, пока базовый модуль не будет готов, затем оба модуля вызывают .upload () в базовом модуле в собственных транзакциях.В какой-то момент задачи будут обновлены (если были изменения).Так что в обоих аддонах были изменения в заданиях, это порождает тупик.

Answer 2

Кажется, что оба запроса обновляют одну и ту же часть B-дерева вашего кластерного индекса.Есть несколько ответов на эту проблему параллелизма.Можно было бы получить более быстрое оборудование.Другой вариант - не иметь первичного ключа, который может измениться.

Сначала я бы спросил вас: обновляете ли вы первичный ключ из двух отдельных запросов?
У вас есть естественный ключ?
У вас установлены каскадные обновления для ваших первичных / внешних ключей?
Какой другой ваш блокирующий запрос?

Включение pk в некластеризованный индекс не принесло успеха

Это потому, что pk всегда находится во всех некластеризованных индексах, как еще он будет выполнять поиск по закладкам?