Что может произойти в результате использования (nolock) для каждого SELECT в SQL Server?

Я понимаю, что подсказка оптимизатора (nolock) позволяет "грязные чтения", но по каким очень конкретным сценариям это плохая идея? Я никогда не видел такого широко распространенного использования (nolock) в организации, и это заставляет меня нервничать. Мне хотелось бы объяснить объяснения пользователей. "Павел делает A, Питер делает B, X происходит вместо Y".

ОТВЕТЫ

Ответ 1

Отмена этого:

NOLOCK означает отсутствие блокировок вообще.

В запросе могут возвращаться части данных до UPDATE и части после UPDATE в одном запросе.

Как, дебет без кредита и таких вещей.

Например, я просто запустил этот запрос в большой таблице:

SELECT  SUM(LEN(name))
FROM    master WITH (NOLOCK)
OPTION (MAXDOP 1)

---
18874367

Все name имеют длину 1.

Затем я повторю его, и в середине запроса обновлена ​​таблица:

UPDATE  master
SET     name = 'tt'
WHERE   id <= 10000

SELECT  SUM(LEN(name))
FROM    master WITH (NOLOCK)
OPTION (MAXDOP 1)

---
18874944

Как мы видим, этот запрос заметил 577 строки как обновленные (длина 2), а все остальные строки не обновлены (длина 1).

SELECT  SUM(LEN(name))
FROM    master WITH (NOLOCK)
OPTION (MAXDOP 1)

---
18884367

И этот запрос запускается сразу после предыдущего, видит все обновления.

Ответ 3

Недавно я потратил много времени на то, чтобы выяснить время и проблемы с блокировкой для процесса сборки хранилища данных. Как оказалось, из-за только для чтения данных для загрузки хранилища я добавил подсказки nolock к запросам исходных данных для etl, чтобы уменьшить потребность в эскалации блокировки на сервере sql и сохранить потерю etl от отказа, Для этого я очень мало контролировал сервер sql и приложение. Опять же, это было целевое решение, и я не рекомендую широко использовать любые подсказки в качестве общего правила. Как и все тесты производительности и обзор, есть ключевые области, на которые нужно обратить внимание, чтобы определить, где находится проблема, и что может быть лучшим способом атаковать ее.