Является NOLOCK (Подсказка SQL-сервера) плохой практикой?
Попробуйте это:
@echo off
copy "C:\Remoting.config-Training" "C:\Remoting.config"
start C:\ThirdParty.exe
exit
4 ответа
С подсказкой NOLOCK уровень изоляции транзакции для оператора SELECT составляет READ UNCOMMITTED . Это означает, что запрос может увидеть грязные и противоречивые данные.
Это не лучшая идея, как правило. Даже если такое поведение грязного чтения подходит для вашего критически важного веб-приложения, сканирование NOLOCK может вызвать ошибку 601, которая завершит запрос из-за перемещения данных в результате отсутствия защиты от блокировки.
Я предлагаю прочитать Когда изоляция снимков помогает и когда это мешает - MSDN рекомендует использовать READ COMMITTED SNAPSHOT вместо SNAPSHOT в большинстве случаев.
До работы над переполнением стека я был против NOLOCK по принципу, что вы потенциально можете выполнить SELECT с NOLOCK ] и получите результаты с данными, которые могут быть устаревшими или несовместимыми. Следует подумать о том, сколько записей может быть вставлено / обновлено одновременно, когда другой процесс может выбирать данные из той же таблицы. Если это происходит часто, то высока вероятность возникновения взаимоблокировок, если вы не используете режим базы данных, такой как READ COMMITED SNAPSHOT .
С тех пор я изменил свой взгляд на использование NOLOCK увидев, как он может улучшить производительность SELECT , а также устранить взаимоблокировки на сильно загруженном SQL Server. Бывают случаи, когда вам может быть все равно, что ваши данные не t точно на 100% привержены, и вам нужно быстро вернуть результаты, даже если они могут быть устаревшими.
Задайте себе вопрос, думая об использовании NOLOCK :
Включает ли мой запрос таблицу с большим количеством команд
INSERT/UPDATEи беспокоюсь ли я о том, что в данных, возвращаемых запросом, могут отсутствовать эти изменения в данный момент?
Если ответ отрицательный, используйте NOLOCK для повышения производительности.
Я только что выполнил быстрый поиск ключевого слова
NOLOCK в базе кода для Stack Overflow и нашел 138 экземпляров, поэтому мы используем его во многих местах. Если вас не волнуют грязные чтения (т.е. в ситуации преимущественно READ), тогда NOLOCK подойдет.
НО , имейте в виду, что большинство проблем с блокировкой происходит из-за отсутствия «правильных» индексов для вашей рабочей нагрузки запроса (при условии, что оборудование соответствует задаче).
И объяснение гуру было правильным. Обычно это пластырь для решения более серьезной проблемы.
Edit : I ' m определенно не предлагает использовать NOLOCK. Думаю, мне следовало это ясно дать понять. (Я бы использовал его только в экстремальных обстоятельствах, когда я проанализировал, что это нормально). В качестве примера, некоторое время назад я работал над некоторым TSQL, который был опрыскан NOLOCK, чтобы попытаться облегчить проблемы с блокировкой. Я удалил их все, установил правильные индексы, и ВСЕ взаимоблокировки исчезли.
Ни один из ответов не является неправильным, но может немного сбивать с толку.
- При запросе отдельных значений / строк всегда плохая практика использовать NOLOCK - вы, вероятно, никогда не захотите отображать неверную информацию или, возможно, даже предпринять какие-либо действия с неверными данными.
- При отображении приблизительной статистической информации NOLOCK может быть очень полезным. Возьмем, к примеру, SO: было бы бессмысленно снимать блокировки для чтения точного количества просмотров вопроса или точного количества вопросов для тега. Никого не волнует, если вы сейчас неправильно зададите 3360 вопросов с тегом «sql-server», а из-за отката транзакции - 3359 вопросов на секунду позже.