SQL Server NOLOCK и соединения
фон: у меня есть критический для производительности запрос, который я хотел бы запустить, и мне плевать на грязные чтения.
мой вопрос: если я использую соединения, должен ли я указать подсказку NOLOCK на них?
например; is:
SELECT * FROM table1 a WITH (NOLOCK)
INNER JOIN table2 b WITH (NOLOCK) ON a.ID = b.ID
эквивалентно:
SELECT * FROM table1 a WITH (NOLOCK)
INNER JOIN table2 b ON a.ID = b.ID
или мне нужно будет указать (NOLOCK) намек на соединение, чтобы убедиться, что я не блокирую присоединенную таблицу?
3 ответов:
Я не буду решать
READ UNCOMMITTEDаргумент, просто ваш первоначальный вопрос.Да, вам нужен
WITH(NOLOCK)на каждой таблице соединения. Нет, ваши запросы не совпадают.попробуйте это упражнение. Начните транзакцию и вставьте строку в таблицы table1 и table2. Не фиксируйте и не откатывайте транзакцию. На этом этапе ваш первый запрос вернется успешно и включит незафиксированные строки; ваш второй запрос не вернется, потому что table2 не имеет
WITH(NOLOCK)намек на оно.
Я был уверен, что нужно указать
NOLOCKдля каждогоJOINв запросе. Но мой опыт был ограничен SQL Server 2005.когда я посмотрел MSDN просто для подтверждения, я не мог найти ничего определенного. Приведенные ниже утверждения, похоже, заставляют меня думать, что для 2008 года Ваши два утверждения выше эквивалентны, хотя для 2005 года это не так:
[SQL Server 2008 R2]
все подсказки блокировки распространяются на все таблицы и представления, которые доступ по плану запроса, включая таблицы и представления, на которые ссылается в представлении. Кроме того, SQL Server выполняет соответствующие проверки согласованности блокировки.
[SQL Server 2005]
В SQL Server 2005 все подсказки блокировки распространяются на все таблицы и представления, на которые ссылается в представлении. Кроме того, SQL Server выполняет соответствующую последовательность блокировки проверяет.
кроме того, обратите внимание - и это относится как к 2005, так и к 2008 году:
табличные подсказки игнорируются, если к таблице не обращается план запроса. Это может быть вызвано тем, что оптимизатор решил вообще не обращаться к таблице или вместо этого получить доступ к индексированному представлению. В последнем случае доступ к индексированному представлению можно предотвратить с помощью
OPTION (EXPAND VIEWS)подсказки в запросе.
ни. Вы устанавливаете уровень изоляции в
READ UNCOMMITTEDчто всегда лучше, чем давать индивидуальные подсказки блокировки. Или, еще лучше, если вы заботитесь о таких деталях, как последовательность используйте изоляция моментального снимка.
Comments