Является ли NOLOCK (подсказка Sql Server) плохой практикой?

Question

Я занимаюсь созданием веб-сайтов и приложений, которые не критически важны -> например. банковское программное обеспечение, космический полет, приложение для мониторинга интенсивной терапии и т. д. Вы поняли.

Итак, с этим массивным отказом от ответственности, плохо ли использовать подсказку NOLOCK в каком-то Sql-выражении? Несколько лет назад один из администраторов Sql предложил мне использовать NOLOCK, если я доволен «грязным чтением», которое даст мне немного большую производительность в моей системе, поскольку каждое чтение не блокирует таблица / строка / все.

Мне также сказали, что это отличное решение, если я испытываю тупики. Итак, я начал следовать этой мысли в течение нескольких лет, пока гуру SQL не помог мне со случайным кодом и не заметил все NOLOCKS в моем SQL-коде. Меня вежливо ругали, и он пытался объяснить это мне (почему это нехорошо), и я как-то заблудился. Я чувствовал, что суть его объяснения состояла в том, что «это бандитское решение более серьезной проблемы ... особенно если вы испытываете взаимоблокировку». Таким образом, исправьте корень проблемы ».

Недавно я немного погуглил по этому поводу и наткнулся на этот пост .

Так, может, какой-нибудь гуру-сэнсей, пожалуйста, просветите меня?

Answer 1

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

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

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

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

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

Answer 2

В реальной жизни, когда вы сталкиваетесь с системами, уже написанными и добавляющими индексы в таблицы, а затем резко замедляющим загрузку данных из таблицы данных 14 ГБ, вы иногда вынуждены использовать WITH NOLOCK в своих отчетах, и в конце месяца выполняется обработка, так что агрегирование Функции (сумма, количество и т. д.) не блокируют строки, страницы, таблицы и не влияют на общую производительность. Легко сказать, что в новой системе никогда не используйте WITH NOLOCK и не используйте индексы - но добавление индексов серьезно снижает загрузку данных, и когда мне тогда говорят, ну, в общем, измените базу кода, чтобы удалить индексы, затем выполните массовую загрузку, а затем заново создайте индексы - что все хорошо, если вы разрабатываете новую систему. Но не тогда, когда у вас уже есть система.