Эффект подсказки NOLOCK в операторах SELECT

Question

Я думаю, реальный вопрос:

Если меня не волнует грязное чтение, добавление подсказки с (NOLOCK) к оператору SELECT повлияет на производительность:

1. текущий оператор SELECT
2. другие транзакции против данной таблицы

Пример:

Select * 
from aTable with (NOLOCK)

Answer 1

1) Да , выбор с помощью NOLOCK завершится быстрее, чем обычный выбор.

2) Да , выбор с NOLOCK позволит другим запросам в отношении обработанной таблицы завершаться быстрее, чем обычный выбор.

С чего бы это?

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

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

Вы действительно не можете узнать, в каком состоянии находятся данные.

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

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

Answer 2

NOLOCK делает большинство операторов SELECT быстрее из-за отсутствия общих блокировок. Кроме того, отсутствие выдачи блокировок означает, что ваш SELECT не будет мешать писателям.

NOLOCK функционально эквивалентен уровню изоляции READ UNCOMMITTED. Основным отличием является то, что вы можете использовать NOLOCK для некоторых таблиц, но не для других, если хотите. Если вы планируете использовать NOLOCK для всех таблиц в сложном запросе, то использовать SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED проще, поскольку вам не нужно применять подсказку к каждой таблице.

Здесь представлена ​​информация обо всех уровнях изоляции, которые имеются в вашем распоряжении, а также табличные подсказки.

УСТАНОВИТЬ УРОВЕНЬ ИЗОЛЯЦИИ СДЕЛКИ

Подсказка к таблице (Transact-SQL)

Answer 3

В дополнение к тому, что сказано выше, вы должны хорошо понимать, что nolock фактически налагает на вас риск не получения строк, которые были зафиксированы до вашего выбора.

См. http://blogs.msdn.com/sqlcat/archive/2007/02/01/previously-committed-rows-might-be-missed-if-nolock-hint-is-used.aspx

Answer 4

Это будет быстрее, потому что не нужно ждать блокировки

Answer 5

• Текущий SELECT начнется раньше, потому что не нужно ждать.

• Другие транзакции замедлятся, поскольку теперь они делятся временем обработки с новой транзакцией.

Не используйте его.

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

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

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

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

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

Есть и другие побочные эффекты, которые приводят к потере скорости, которую вы надеялись получить в первую очередь.

Теперь вы знаете, никогда не используйте его снова.