Следует ли заменить все подзапросы временными таблицами?

Я работал над решением (в SQL Server), в котором все подзапросы без исключения были переписаны с временными таблицами для повышения производительности.

Для примера, все запросы такие:

SELECT something 
FROM (SELECT * FROM T1 WHERE condition1) 
JOIN ...

были переписаны так:

SELECT * 
INTO #tempTable 
FROM T1 
WHERE condition1

SELECT something 
FROM #tempTable  
JOIN ...

Также было предложено здесь избегать всех подзапросов в пользу временных таблиц.

Основываясь на данных фактах, следует ли заменить все подзапросы временной таблицей? Если нет, то когда следует рассматривать одно над другим?


person Arvand    schedule 13.03.2017    source источник
comment
Здесь уже дан ответ:‹br/› stackoverflow.com/questions/16767645/ и это: ‹br/› stackoverflow.com/questions /2825342/   -  person Putra Christianto Purba    schedule 13.03.2017
comment
Единственное абсолютное правило без исключений в сервере sql - это зависит. Я бы сказал весьма решительно, что простое слепое преобразование каждого подзапроса во временную таблицу является бесполезным и бесполезным упражнением. В некоторых случаях это может повысить производительность, но в других, скорее всего, ухудшит ее. Рассмотрим подзапрос с миллионом строк. Хотя это может быть не лучшим способом написания кода, копирование такого большого количества данных во временную таблицу будет медленнее. И в лучшем случае вы можете исправить проблему с производительностью, которой даже не существует.   -  person Sean Lange    schedule 13.03.2017
comment
Это в значительной степени ответ, который вы ищете: stackoverflow.com/a/11169910/2333499   -  person SqlZim    schedule 13.03.2017


Ответы (2)


Это смешно. Шутка.

Ваш «подзапрос» в порядке. SQL Server просто игнорирует это. Вы можете переписать его так:

SELECT something
FROM T1 JOIN . . .
WHERE condition1

SQL Server должен оптимизировать это правильно.

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

Если нужна временная таблица, то почти всегда в ней будут индексы. Это одна из основных причин использования временной таблицы. (Два других связаны с тем, что один и тот же блок запроса повторяется в одном или нескольких запросах).

person Gordon Linoff    schedule 13.03.2017
comment
Также есть хорошая ссылка, которую дал @SqlZim. Временные таблицы - это другое дело, потому что вы даете больше рекомендаций о том, как следует выполнять запрос. Одним из основных отличий является то, что оптимизатор может использовать статистику из временной таблицы для создания своего плана запроса. Это может привести к увеличению производительности. Ответ дал... ммм... - person David דודו Markovitz; 13.03.2017
comment
@scsimon - Следовательно, ответ был дан ... ммм ... :-) - person David דודו Markovitz; 13.03.2017
comment
Это была вторая ссылка во втором ответе из ссылки, которую ОП разместил в своем вопросе. Вероятно, он заслуживает одобрения за ссылку на хороший источник: stackoverflow.com/a/16768252/2333499 - person SqlZim; 14.03.2017

В обсуждении подзапросов я редко вижу один момент: человеческий фактор, а именно читабельность вложенных объектов и сопровождаемость кода.

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

Более того, то, что начинается как простой подзапрос, может стать более сложным, и в этот момент вам, возможно, придется извлечь подзапрос во временную таблицу, чтобы сделать его удобочитаемым/справиться с реальными проблемами производительности (типа того, что упоминал Гордон Линофф ). В зависимости от того, насколько члены команды чувствуют себя комфортно с таким рефакторингом и любой зависимостью от скриптов, использующих подзапросы (например, с хранимыми процедурами), такая возможность добавления времени на рефакторинг может означать, что менеджер введет временные таблицы как стиль предпочтение так же, как и "повышение производительности".

person Myles    schedule 13.12.2018