Использование WITH (NOLOCK) для увеличения производительности

Question

Я видел разработчиков, использующих WITH (nolock) в запросе, есть ли у него какой-либо недостаток?Кроме того, каков режим выполнения запроса по умолчанию?В моей базе данных нет индекса.

Есть ли другой способ повысить производительность оператора выбора базы данных?

Answer 1

Распространенным заблуждением с nolock является то, что он не устанавливает блокировку базы данных во время выполнения.Технически он выдает блокировку стабильности схемы (sch-s), поэтому часть блокировки «нет» относится к стороне данных запроса.

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

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

Answer 2

В сети множество статей на эту тему.Основной риск заключается в том, что с NOLOCK вы можете читать несвязанные данные из таблицы (грязное чтение).См., Например, http://msdn.microsoft.com/en-us/library/aa259216(v=sql.80).aspx или http://www.techrepublic.com/article/using-nolock-and-readpast-table-hints-in-sql-server/6185492

Answer 3

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

У вас есть хранимая процедура для доступа к данным неактивных проектов. Вы не хочу, чтобы эта хранимая процедура блокировала часто используемые проекты таблица при чтении старых данных.

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

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

Однако, начиная с SQL Server 2005, преимущества NOLOCK очень малы из-за контроля версий строк.