синтаксис NOLOCK в SQL

Question

Я видел SQL заявления с помощью NOLOCK и с (NOLOCK) например -

select * from table1 nolock where column1 > 10 

И

select * from table1 with(nolock) where column1 > 10 

Какой из приведенных выше утверждений является правильным и почему?

Answer 1

Они оба технически правильны, однако not using the WITH keyword has been deprecated с SQL 2005, поэтому привыкнуть к использованию ключевого слова WITH - короткий ответ, используйте ключевое слово WITH.

Answer 2

Используйте "WITH (NOLOCK)".

Answer 3

Первое утверждение ничего не блокирует, а второе. Когда я тестировал на это только сейчас на SQL Server 2005, в

select * from table1 nolock where column1 > 10 --INCORRECT 

«NOLOCK» стал псевдоним, в этом запросе, из table1.

select * from table1 with(nolock) where column1 > 10 

выполняет желаемую функциональность nolock. Скептически? В отдельном окне запустите

BEGIN TRANSACTION 
UPDATE tabl1 
set SomeColumn = 'x' + SomeColumn 

Чтобы заблокировать стол, а затем попробуйте каждую операцию блокировки в отдельном окне. Первый будет зависать, ожидая освобождения блокировки, а второй будет работать сразу (и покажет «грязные данные»). Не забудьте выпустить

ROLLBACK 

Когда вы закончите.

Answer 4

Список устаревших функций находится в Deprecated Database Engine Features in SQL Server 2008:

• Указание NOLOCK или READUNCOMMITTED в ЕКОМ в UPDATE или ВЕЬЕТЕ.
• Указание таблицы подсказки без использования ключевого слова WITH.
• HOLDLOCK настольная подсказка без скобка
• Использование пространства в качестве разделителя между настольными подсказками.
• Косвенное применение табличных подсказок для вызова многозначной табличной функции (TVF) через представление.

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

Это сказанное мой 2с по этому вопросу, как таковые:

• Оба from table nolock и from table with(nolock) неверны. Если вам нужны грязные чтения, вы должны использовать соответствующие уровни transaction isolation: set transaction isolation level read uncommitted.Таким образом, используемый уровень искры четко излагается и контролируется одним «ручкой», а не распространен через источник и подчиняется всем причудам табличных подсказок (косвенное применение через представления и ТВФ и т. Д.).

• Грязные чтения являются отсрочкой. Что нужно, в 99,99% случаев, это сокращение конкуренции, а не чтение незафиксированных данных. Конфликт уменьшается путем написания правильных запросов по хорошо продуманной схеме и, при необходимости, путем развертывания изоляции моментальных снимков. Лучшее решение, которое решает произведения почти всегда сохранять несколько крайних случаев, является enable read commited snapshot в базе данных и дайте двигателю работать свою магию:

  ALTER DATABASE MyDatabase SET ALLOW_SNAPSHOT_ISOLATION ON
ALTER DATABASE MyDatabase SET READ_COMMITTED_SNAPSHOT ON

удалите все подсказки из выбирает.

Answer 5

Оба синтаксически правильные.

NOLOCK станет псевдонимом для таблицы1.

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

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

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

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

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

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

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