Вот статья. Там же комментарии.
http://1cexpo.ru/metodiki/20-tipichnye-prichiny-neoptimalnoj-raboty-zaprosov-i-metody-optimizaczii.html
В двух словах: автор статьи утверждает, что соединять вложенные запросы с реальными таблицами напрямую нельзя. Требуется предварительно поместить вложенный запрос во временную таблицу.
В комментариях мнение оспаривается. Указывается на то, что временные таблицы хранятся на диске и поэтому СУБД работает с ними порядок медленнее.
Примем за аксиому, что код запроса у нас формируется динамически (т.е. сложность запроса варьирует), и кол-во данных в выборках тоже может быть разным.
Какой способ соединения вы бы использовали и почему?

Тот ккоторый удобней. И который лучше план запроса выдаст

Зависит от данных. Соединение с вложенным запросом может привести к выбору неправильного плана запроса СУБД, что в некоторых случаях может вызвать потерю производительности на порядок

(1) ты у каждого своего запроса смотришь план? я нет, будут проблемы - тогда и смотреть

(3) Я смотрю :-)

(1)(2)
Видимо предпоследнее предложение никто не прочитал. Отсюда и комментарии "который лучше план запроса", "зависит от данных".
Повторяю: Код запроса формируется динамически. Т.е. один раз это простейший запрос с одним вложенным и тремя записями в двух таблицах, в другой раз это запрос со 100500 вложениями и миллиардами записей в таблицах.

(0) а нам пох

(4) я не сомневался в тебе)

Вложенные нужны для специфических случаев.
Соединить временную таблицу с собой же для поиска Минимумов, к примеру, чебынет.

(6) Отлично!

(5) тогда ты должен понимать что зависит от ситуации. Если такая неопределённость - я за ВТ. Там план запроса будет строится с учетом данных. Затраты на создание ВТ есть конечно, но они милипусидрические

(5) Идиотское требование.

"Делайте временными, а там SQL разбереться"

Че там, временные? Ну дадут просадку в сотни 3 миллисекунд на вставку, зато гарантированно не дадут физдеца в виде зарослей Nested Loops

(11) Без этого требование все писали бы что-то типа "зависит от ситуации". Поэтому рассматриваем случай "сферического коня в вакууме".

(13) тогда (6)

так

Конечно, при прогретом кэше SQL -ю побоку, что у него там 80000 reads в одном запросе, а вы попробуйте это сделать, когда SQL только стартанул или кэш кончился.

Гораздо интереснее другой вопрос - вы бы добавили Индекс на измерение в регистр, дико пользуемый при проведении всех товарных, при условии, что этот индекс будет пользоваться в 1-ой печатной форме, и то в 10% случаев.

(6)(14) Счастливые люди. У них много свободного времени, которое можно убить на написание бесполезных комментариев. )

(18) А ты?

(19) А я пытаюсь что-то новое узнать. )

(20) Ну и как?

(21) Пока получается.

(0) 3-5 миллисекунд на создание временной таблицы - это экономия на спичках.
Всегда помещаю во временную, хотя бы потому, что читать запрос удобнее

(23) Да не 3-5, а поболее.

(0)  соединения с вложенными запросами в принципе зло. Это прямо даже на сайте 1С написано

(25) Замену им увы не придумали.

(3)  а и то правильно - зачем думать о производительности до отправки кода в продуктив? Вот когда жопа по швам начнет трещать от управляющих воздействий, вот тогда и будем думать

(26) не пори

Статья, мягко говоря, не шибко грамотная. Неизвестный автор заявляет безапелляционно: "Следует соединять друг с другом только объекты метаданных или временные таблицы. Если запрос использует соединения с подзапросами, то его следует переписать." Когда доходит до аргументации, начинается невнятное "не всегда", "СУБД может ошибиться", "зависит от" и т.д. Очевидно, что не бывает одного решения на все случаи жизни. Если бы автор выделил какие-то классы запросов и убедительно показал, что да, вот здесь оптимизатор ошибется, надо однозначно переписать на ВТ. Но нет, рубим сплеча.

Если посмотреть на типовые, то видно что там используются и ВТ и подзапросы. Видимо неспроста.

"Переписанный подобным образом запрос будет работать одинаково хорошо на любых СУБД, что особенно важно при разработке тиражных решений."

Это ложь. На файловой базе по сети ВТ тормозят еще как, иногда хоть вешайся. Ведь база с таблицами на сервере, а ВТ создаются на клиенте в виде временных файлов.

(27) о производительности я думаю всегда, и мне хватает в общем случае мозга правильно написать запрос, а не выяснять это путём просмотров плана запроса, причем он варьируется от данных, регл обслуживания субд и т.д., Что в общем случае не даст мне выявить "ошибку" на продакшн базе, ибо её ещё нет природе

(29) Автор статьи довольно известен - это Константин Рупасов. По ссылке в (0) перепост его статьи на kb.1c.ru
Тема относится к проблемам производительности в клиент-серверном варианте

(29) да, рупасов "Неизвестный автор". так и запишем :)

>>На файловой базе по сети ВТ тормозят еще как, иногда хоть вешайся
ларьки идут лесом и считают в экселе. Целевая аудитория может позволить себе купить скуль, или поставить бесплатный постгри

(29)   а аргумент именно такой и есть - ты хрен угадаешь, какой план запроса построен будет, но шансов на успех меньше, чем на удачу.
Конечно, есть случаи, когда использование соединений с вложенными запросами оправдано с точки зрения производительности. Но их мало и они индивидуальны. А вот случаев, когда вложенные запросы повышают читабельнсть и облегчают сопровождения просто не бывает. Вообще.

(31) Будем знать. Отчего же его постеснялись назвать по ссылке?