Увеличивает ли количество with (Nolock) ограничение конкуренции при выборе из временных таблиц или SQL Server достаточно умен, чтобы не создавать конфликты в временных таблицах в первую очередь?
PS: Да, я знаю об опасности READUNCOMMITTED.
select * from #myTempTable
против
select * from #myTempTable with (nolock) --is this faster?
Вы можете использовать флаг трассировки 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 в версии кучи объясняется здесь. Но можно видеть, что накладные расходы на блокировку практически минимальны.
Это вряд ли может иметь большое значение, поскольку область временных таблиц - это одно и то же соединение.
Вы только конкурируете за блокировки с собой в том же соединении, и если вы читаете временную таблицу, то вы, вероятно, единственный, кто делает это.
В целом, вероятно, лучше не переустраивать и не доверять механизму запросов SQL Server, чтобы хорошо выполнять свою работу. Подождите, пока у вас возникнет проблема, прежде чем пытаться что-то исправить.
EDIT (слегка не по теме): (обновленная ссылка)
Тем не менее, существует некоторое обсуждение вокруг воздействия на весь tempdb при создании временной таблицы. Возможно, будет оптимизировано - см. Здесь варианты (однако это старая статья - SQL Server 6.5/7.0), и ее вероятный SQL Server 2000 вверх с этим сценарием автоматически
Опять же, я рекомендую подождать, пока у вас не возникнет проблема, прежде чем усложнить решение.
В зависимости от вашего запроса это может иметь огромное значение. Я сократил время выполнения запроса с 1295 до 590, просто добавив WITH (NO LOCK) в мою временную таблицу. Результаты могут отличаться.