WITH (NOLOCK) vs SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

Может ли кто-нибудь дать мне совет, когда мне следует использовать, WITH (NOLOCK)а неSET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

Какие плюсы / минусы у каждого? Есть ли какие-либо непредвиденные последствия, с которыми вы столкнулись при использовании одного по сравнению с другим?

Это одно и то же. Если вы используете set transaction isolation levelоператор, он будет применяться ко всем таблицам в соединении, поэтому, если вы хотите использовать только nolockодну или две таблицы, используйте его; в противном случае используйте другой.

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

WITH (NOLOCK) - подсказка на уровне таблицы. Установка уровня изоляции транзакции READ_UNCOMMITTED с воздействием на соединение. Разница лишь в объеме. Смотрите READUNCOMMITTED и NOLOCK в документации по SQL Server здесь:

http://technet.microsoft.com/en-us/library/ms187373.aspx

Для УРОВНЯ ИЗОЛЯЦИИ ТРАНЗАКЦИИ: http://technet.microsoft.com/en-us/library/ms173763.aspx

• NOLOCK является локальным для таблицы (или представлений и т. Д.)
• READ UNCOMMITTED - за сеанс / соединение

Что касается рекомендаций ... случайный поиск из StackOverflow и электрического интернета ...

• Является ли NOLOCK (подсказка Sql Server) плохой практикой?
• Когда уместно использовать NOLOCK?
• Избавьтесь от этих NOLOCK-подсказок…

Насколько мне известно, единственная разница - это объем эффектов, как сказал Стромми. Подсказка NOLOCK для таблицы и READ UNCOMMITTED на сеансе.

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

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

Также я считаю, что в наши дни вам следует изучить Multi-version Concurrency Control. Я считаю, что они добавили его в 2005 году, и он помогает авторам не блокировать читателей, предоставляя читателям моментальный снимок базы данных для использования. Я добавлю ссылку и оставлю читателю дальнейшие исследования:

MVCC

Уровни изоляции базы данных

Вы не можете использовать Set Transaction Isolation Level Read Uncommitted в представлении (на самом деле у вас может быть только один скрипт), поэтому вам придется использовать (nolock), если должны быть включены грязные строки.

Поскольку вам нужно использовать WITH (NOLOCK) для каждой таблицы, может быть неприятно писать его в каждом предложении FROM или JOIN. Однако есть причина, по которой это называется «грязным» чтением. Поэтому вам действительно следует знать, когда вы это делаете, а не устанавливать его по умолчанию для области сеанса. Зачем?

Забывание WITH (NOLOCK) может не сильно повлиять на вашу программу, однако выполнение грязного чтения там, где вы не хотите, может иметь значение в определенных обстоятельствах.

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