nolock для временной таблицы в SQL Server 2008

Question

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

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

select * from #myTempTable

против

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

Answer 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 таблиц.Я воспроизвожу эту часть вывода ниже

#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 для версии кучи - , объясненная здесь .Но можно видеть, что накладные расходы довольно минимальны.

Answer 2

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

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

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

РЕДАКТИРОВАТЬ (слегка не по теме): (обновленная ссылка)

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

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

Answer 3

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