Использование NOLOCK для чтения одной статической строки. Какой вред?

Question

Может ли кто-нибудь с опытом DEADLOCK просветить меня?

Я читал, что это может привести к повреждению файла журнала - это возможно? Я думаю, что MS никогда этого не сделает. Также, если «некоторые ситуации», как и мои, в порядке с DEADLOCK, почему бы не использовать его?

У меня нет наборов данных, таблицы возврата (как и другие сообщения в переполнении стека). У меня есть один оператор SQL с идентификатором select, который возвращает только одну строку:

sqlstr = "SELECT Parameter1 FROM Companies WITH (NOLOCK) WHERE ID = 25 

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

Каждое сообщение на этом сайте содержит несколько записей, записей, пакостных чтений. Я ничего не мог найти о «чтении одной записи, которая не меняется все время».

Любое мнение эксперта, пожалуйста?

Answer 1

После глубоких поисков и заданий многих экспертов я узнал, что использование подсказки NOLOCK не вызывает никаких проблем в этом сценарии, но не рекомендуется. ничего плохого в NOLOCK, но поскольку я использую sql2014, я должен использовать опцию ISOLATION LEVEL. Его метод появился вместо NOLOCK. Например, для огромных таблиц, которые вызывают взаимоблокировки:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; 
BEGIN TRANSACTION; 
SELECT * FROM HugeTable; 
COMMIT TRANSACTION; 

очень удобно.

У меня была HugeTable и веб-форма, которая использует sqlAdapter и Radgrid для отображения этих данных. Всякий раз, когда я запускаю этот отчет, хотя индексы и пейджинг radgrid в порядке, это вызвало тупик, что имеет смысл. Я изменил выбранную инструкцию sqlAdapter на вышеприведенное предложение, теперь это идеально.

лучший.

Answer 2

Этот простой оператор select при выполнении без каких-либо намеков блокировки/нолока по уровню изоляции транзакций по умолчанию получает общую блокировку в строке. Это означает, что другие пользователи могут также читать эту строку, пока ее читают по этому запросу.

С другой стороны, когда вы указываете подсказку WITH (NOLOCK), он вообще не получает никаких замков. В этом случае другие пользователи также могут прочитать эту строку, но вы можете читать грязную строку (данные, которые еще не были записаны на диск и находятся в процессе изменения).

Таким образом, в любом случае этот простой выбор не приведет к взаимоблокировке. Так что действительно вопрос, который вы должны задавать себе, заключается в том, должны ли пользователи видеть грязные данные или нет? и в большинстве случаев ответ будет отрицательным.

Поэтому не беспокойтесь о получении взаимоблокировок с этим запросом на выбор. до тех пор, пока вы используете уровень изоляции транзакций по умолчанию. В более строгом уровне изоляции, таком как seriallizable, select может блокировать других пользователей, но при уровне изоляции по умолчанию вы должны быть в порядке.

Answer 3

NOLOCK имеет два основных недостатка: он может возвращать незафиксированные данные (вы, похоже, не беспокоитесь об этом), и это может вызвать ложные ошибки при очень редких обстоятельствах. Никогда не будет NOLOCK привести к повреждению физической базы данных.

Рассмотрите возможность использования изоляции моментальных снимков для транзакций, которые только считывают данные. Читатели под SI не блокируют и не блокируют. SI выводит их из картинки. Он обеспечивает идеальную согласованность транзакций только для чтения. Обязательно узнайте о недостатках.

Answer 4

Не стоит.

NOLOCK часто используется как волшебный способ ускорить чтение базы данных, но я стараюсь избегать его использования.

Результирующий набор может содержать строки, которые еще не были зафиксированы, которые часто позже откатываются назад.

Ошибка или набор результатов могут быть пустыми, пропускать строки или отображать одну и ту же строку несколько раз.

Это связано с тем, что другие транзакции перемещают данные одновременно с чтением.

READ COMMITTED добавляет дополнительную проблему, когда данные повреждаются в пределах одного столбца, когда несколько пользователей одновременно меняют одну и ту же ячейку.

Есть и другие побочные эффекты, которые приводят к жертве увеличения скорости, которое вы надеялись получить в первую очередь.

Теперь вы знаете, никогда не используйте его снова.