Может ли добавление столбца идентификации первичного ключа решить проблемы взаимоблокировки?
У меня есть таблица на сервере SQL, которая одновременно обрабатывается CRUD хранимой процедурой, работающей одновременно в разных сеансах:
|----------- -----|---------|
| <некоторые столбцы> | JobGUID |
|----------------|----------|
Процедура работает следующим образом:
- Создайте GUID.
- Вставьте несколько записей в общую таблицу, описанную выше, пометив их GUID из шага 1.
- Выполните несколько обновлений всех записей из шага 2.
- Выберите записи из шага 3 в качестве выходных данных SP.
Каждый оператор выбора/вставки/обновления/удаления в хранимой процедуре имеет предложение WHERE JobGUID = @jobGUID, поэтому процедура работает только с записями, вставленными на шаге 2. Однако иногда, когда одна и та же хранимая процедура выполняется параллельно в разных соединениях, взаимоблокировки возникают в общей таблице. Вот график взаимоблокировок из SQL Server Profiler:
Расширение блокировок не происходит. Я пробовал добавлять (UPDLOCK, ROWLOCK)подсказки блокировки ко всем операторам DML и/или оборачивать тело процедуры в транзакцию и использовать разные уровни изоляции, но это не помогло. Все та же блокировка RID для общей таблицы.
После этого я обнаружил, что в общей таблице нет столбца первичного ключа/идентификации. И как только я его добавил, взаимоблокировки, похоже, исчезли:
alter table <SharedTable> add ID int not null identity(1, 1) primary key clustered
Когда я удаляю столбец первичного ключа, взаимоблокировки возвращаются. Когда я добавляю его обратно, я больше не могу воспроизвести тупик.
Итак, вопрос в том, действительно ли столбец идентификации первичного ключа может разрешать тупиковые ситуации или это просто совпадение?
Обновление: как предлагает @Catcall, я попытался создать естественный кластеризованный первичный ключ для существующих столбцов (без добавления столбца идентификаторов), но все равно поймал ту же тупиковую ситуацию (конечно , на этот раз это была ключевая блокировка, а не RID-блокировка).