Когда уместно использовать NOLOCK?

Используйте его, когда допустимо грязное чтение и фантомные записи. Т.е. у вас могут регулярно запускаться некритические отчеты, если точность информации не является основным драйвером, но имеет представление об объеме записи, или какая-то другая метрика, например

Use nolock as a last resort. Most deadlock problems can be fixed by tuning the queries and/or tuning the indexes. I think I've seen one deadlock in the last 5 years that couldn't be fixed by tuning one of the two.

Also note that NOLOCK is only honoured on select statements. Data modifications will always lock, that behaviour cannot be changed. So if you're got a writer/writer deadlock (quite common), no lock won't help at all.

Also be aware that nolock, in addition to returning dirty data can result in duplicate rows (rows read twice from the underlying table) and missing rows (rows in the underlying table that weren't read at all).

Nolock essentially means to SQL Server 'I don't mind if my results are slightly inaccurate'

Snapshot isolation is an option. Just make sure that you test carefully first as the increased load on TempDB can be quite severe, depending how frequent and long your transactions are. Also note that while you won't see deadlocks in snapshot isolation, you can get update conflicts. Again, test and make sure that your apps work properly and can handle any errors that they get.

В SQL Server существует четыре уровня изоляции транзакций :

1. READ UNCOMMITTED
2. READ COMMITTED
3. REPEATABLE READ
4. SERIALIZABLE

Для Таблицы, к которым он применяется, NOLOCK является эквивалентом «read uncommitted». Это означает, что вы можете видеть строки из транзакций, которые могут быть откатаны в будущем, и многие другие странные результаты.

Тем не менее, на практике nolock работает очень хорошо. Особенно для запросов только для чтения, где отображение немного неправильных данных не конец света, как бизнес-отчеты. Я бы избегал его рядом с обновлениями или вставками, или вообще где-нибудь рядом с кодом для принятия решений, особенно если он включает счета-фактуры.

В качестве альтернативы nolock рассмотрим «моментальный снимок с фиксацией чтения», который предназначен для баз данных с интенсивным чтением и менее. написать деятельность. Вы можете включить его с помощью:

ALTER DATABASE YourDb SET READ_COMMITTED_SNAPSHOT ON;

Он доступен для SQL Server 2005 и выше. Это то, как Oracle работает по умолчанию, и это то, что использует сам stackoverflow. Об этом даже есть запись в блоге ужасов кодирования .

PS Длительные запросы и взаимоблокировки также могут указывать на то, что SQL Server работает с неверными предположениями. Проверьте, не устарели ли ваши статистические данные или индексы:

SELECT 
    object_name = Object_Name(ind.object_id),
    IndexName = ind.name,
    StatisticsDate = STATS_DATE(ind.object_id, ind.index_id)
FROM SYS.INDEXES ind
order by STATS_DATE(ind.object_id, ind.index_id) desc

Статистика должна обновляться в еженедельном плане обслуживания.

Обратите внимание, что вы можете указать nolock для каждой таблицы.

Обычно я использовал nolock в сложных запросах SELECT, но только для небольших справочных таблиц, которые почти никогда не менялись, и для отображения только данные. Вам известны таблицы, в которых перечислены цены за текущее полугодие, или просмотры идентификаторов в строках и т. Д. Материал, который меняется только при серьезных обновлениях, после чего серверы обычно все равно обычно перезапускаются.

Это значительно улучшило производительность, уменьшило вероятность из-за тупика в самые загруженные времена, и что еще более важно, он был действительно заметен в наихудшие моменты для запросов, которые затрагивали множество таблиц (что логично, они должны получать меньше блокировок, и эти боковые таблицы часто используются почти везде, часто уменьшаясь от 7-8 до 4 таблиц, которые нужно заблокировать)

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

Не используйте его для критически важных вещей, вычислений и т. Д., Потому что он станет непоследовательным, все, что приведет к записи раньше или позже.

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

Если в вашей базе данных относительно низкий процент записей, это может не стоить этого. У меня было отношение чтения: записи менее 2: 1.

Некоторые URL-адреса, которые я сохранил, работая над этим:

http://www.developerfusion.com/article/1688/sql-server-locks/4/

Вы должны использовать nolock, когда можно читать грязные данные. Большая транзакция, которая может внести ряд изменений в базу данных, все еще может быть в процессе, использование nolock просто вернет данные, которые она установила до сих пор. Если после этой транзакции откат данных, которые вы просматриваете, может быть неправильным. Следовательно, вы должны использовать его только тогда, когда не имеет значения, что то, что вы получаете, может быть неправильным.

Взаимные блокировки - обычная проблема, но 9 раз из 10 полностью вызваны проблемой разработчика. Я бы сосредоточился на поиске причины тупиков, а не на использовании nolock. Скорее всего, одна транзакция делает все в другом порядке, чем все остальные.

Для согласованного с точки зрения транзакций представления без блокировок чтения рекомендуется включить изоляцию моментальных снимков в SQL Server.

Это немного отличается от NOLOCK в том, что при чтении информации результаты всегда отражают версию зафиксированных данных. а не возможность просмотра незафиксированных данных. Это обеспечивает тот же параллельный блокировочный процесс, что и NOLOCK (без блокировок «чтения»), с более четкими результатами.

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

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

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

На мой взгляд, лучший подход - это всегда «перепроверять»