Взаимоблокировка транзакций для запроса select
иногда у меня есть следующая ошибка для хранимой процедуры, которая является только запросом Select:Transaction (Process ID 91) was deadlocked on lock
мое первоначальное понимание заключалось в том, что запрос select не блокирует таблицу или не вызывает взаимоблокировки, даже если таблица, которую он пытается запросить, обновляется/блокируется другим процессом, но кажется, что запрос select также может вызвать взаимоблокировки.
Если я установлю уровень изоляции для чтения uncommitted для запроса, это решит проблему?
3 ответов
мое понимание init заключается в том, что выбор запрос не блокируете таблицу, или не вызвать тупик
это понимание неверно. Запросы SELECT принимают общие блокировки для строк, которые они анализируют. Общие блокировки могут конфликтовать исключительные блокировки из инструкций update/delete/insert. Две инструкции SELECT не будут взаимоблокироваться, но SELECT может взаимоблокироваться с обновлением. При возникновении такой взаимоблокировки SELECT обычно является жертвой, поскольку он не выполнял никакого обновления, поэтому всегда будет терять ничью.
Как и в любом взаимоблокировке, вам нужно опубликовать точную схему задействованных таблиц, точные инструкции T-SQL и график взаимоблокировки. См.как сохранить графики взаимоблокировки (SQL Server Profiler). С помощью этой информации вы можете получить руководство, как исправить взаимоблокировку.
Как говорит Ремус, вы получаете взаимоблокировки, потому что выберите и обновите (или другие) операции взаимоблокировки, а не Выберите vs SELECT. Вам нужно будет просмотреть все ваши запросы, касающиеся этой таблицы, и создать соответствующие индексы покрытия для этих запросов, и это решит ваши проблемы. Хорошие индексы покрытия-предпочтительное решение, а не использование с (nolock) табличными подсказками.
см. ниже ссылке для хорошего учебника о том, как создать покрытие индексы и как это влияет на взаимоблокировки.
Если вы используете SQL Server 2008, Вы можете установить уровень изоляции для чтения незафиксированным, чтобы предотвратить взаимоблокировку. Смотрите это ссылке. При чтении uncommitted или с (NOLOCK) необходимо знать, что данные, возвращаемые запросом, могут быть нереальными!