синтаксис для nolock в sql

Question

Я видел SQL-операторы, использующие nolock и с (nolock) например, -

select * from table1 nolock where column1 > 10

И

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

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

Answer 1

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

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

"nolock" стал псевдонимом в этом запросе таблицы 1.

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

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

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

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

ROLLBACK

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

Answer 2

Список устаревших функций: Устаревшие возможности компонента Database Engine в SQL Server 2008 :

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

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

Как говорится, мои 2c по этому вопросу таковы:

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

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

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

Затем удалите ВСЕ подсказки из выбора.

Answer 3

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

Answer 4

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

Answer 5

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

NOLOCK станет псевдонимом для table1.

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

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

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

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

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

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

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