Nolock в таблице temp в SQL Server 2008

Увеличивает ли количество with (Nolock) ограничение конкуренции при выборе из временных таблиц или SQL Server достаточно умен, чтобы не создавать конфликты в временных таблицах в первую очередь?

PS: Да, я знаю об опасности READUNCOMMITTED.

select * from #myTempTable

против

select * from #myTempTable with (nolock) --is this faster?

Ответ 1

Вы можете использовать флаг трассировки 1200 (на машине разработки, так как я думаю, что это глобально), чтобы увидеть блокировки, извлеченные для себя

SET NOCOUNT ON;

CREATE TABLE ##T
(
X INT
)

INSERT INTO ##T 
SELECT number
FROM master..spt_values

CREATE TABLE #T
(
X INT
)
INSERT INTO #T
SELECT *
FROM ##T

/*Run the commands first with the trace flag off so the locking
info is less full of irrelevant stuff about plan compilation 
*/
GO

PRINT '##T Read Committed'
SELECT COUNT(*) FROM ##T
PRINT '##T NOLOCK'
SELECT COUNT(*) FROM ##T WITH (NOLOCK)
PRINT '##T Finished'

GO

PRINT '#T Read Committed'
SELECT COUNT(*) FROM #T
PRINT '#T NOLOCK'
SELECT COUNT(*) FROM #T WITH (NOLOCK)
PRINT '#T Finished'

GO

DBCC TRACEON(-1,3604)
DBCC TRACEON(-1,1200)

GO

PRINT '##T Read Committed'
SELECT COUNT(*) FROM ##T
PRINT '##T NOLOCK'
SELECT COUNT(*) FROM ##T WITH (NOLOCK)
PRINT '##T Finished'

GO

PRINT '#T Read Committed'
SELECT COUNT(*) FROM #T
PRINT '#T NOLOCK'
SELECT COUNT(*) FROM #T WITH (NOLOCK)
PRINT '#T Finished'

GO

DBCC TRACEOFF(-1,3604)
DBCC TRACEOFF(-1,1200)

DROP TABLE ##T
DROP TABLE #T

Для глобальной таблицы temp это неудивительно, что имеет большее значение.

Тем не менее, существует небольшая разница в типе блокировки для локальных таблиц #temp. Я воспроизвожу эту часть вывода ниже

#T Read Committed
Process 56 acquiring IS lock on OBJECT: 2:301244128:0  (class bit0 ref1) result: OK

Process 56 acquiring S lock on OBJECT: 2:301244128:0  (class bit0 ref1) result: OK

Process 56 releasing lock on OBJECT: 2:301244128:0 

#T NOLOCK
Process 56 acquiring Sch-S lock on OBJECT: 2:301244128:0  (class bit0 ref1) result: OK

Process 56 acquiring S lock on HOBT: 2:9079256880114171904 [BULK_OPERATION] (class bit0 ref1) result: OK

Process 56 releasing lock on OBJECT: 2:301244128:0 

Изменить: Вышеуказанные результаты для кучи. Для временных таблиц с кластерным индексом результаты ниже.

#T Read Committed
Process 55 acquiring IS lock on OBJECT: 2:1790629422:0  (class bit0 ref1) result: OK

Process 55 acquiring S lock on OBJECT: 2:1790629422:0  (class bit0 ref1) result: OK

Process 55 releasing lock on OBJECT: 2:1790629422:0 

#T NOLOCK
Process 55 acquiring Sch-S lock on OBJECT: 2:1790629422:0  (class bit0 ref1) result: OK

Process 55 releasing lock on OBJECT: 2:1790629422:0 

#T Finished

Причина блокировки BULK_OPERATION в версии кучи объясняется здесь. Но можно видеть, что накладные расходы на блокировку практически минимальны.

Ответ 2

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

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

В целом, вероятно, лучше не переустраивать и не доверять механизму запросов SQL Server, чтобы хорошо выполнять свою работу. Подождите, пока у вас возникнет проблема, прежде чем пытаться что-то исправить.

EDIT (слегка не по теме): (обновленная ссылка)

Тем не менее, существует некоторое обсуждение вокруг воздействия на весь tempdb при создании временной таблицы. Возможно, будет оптимизировано - см. Здесь варианты (однако это старая статья - SQL Server 6.5/7.0), и ее вероятный SQL Server 2000 вверх с этим сценарием автоматически

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

Ответ 3

В зависимости от вашего запроса это может иметь огромное значение. Я сократил время выполнения запроса с 1295 до 590, просто добавив WITH (NO LOCK) в мою временную таблицу. Результаты могут отличаться.