Добрый день. Есть запрос - некая основная таблица, к ней левым соединением присоединяется вложенный запрос. Недавно коллега убеждал что это приводит к циклическому выполнению вложенного запроса для каждой строки основной таблицы.
Помогите разобраться с вопросом - что же происходит:
1) Вложенный циклически исполняется для основной с фильтром по полям соединений
2) Вложенный циклически исполняется и для каждой строки возвращает весь свой результат - который далее обрезается по значениям полей соединений
3) Вложенный исполняется один раз, затем кэшится и п.2

Я как-то спинным мозгом чувствую что п.3 - не нашел на ИТС исчерпывающей инфы по этому вопросу. Конечно нужно поднять дома скуль и посидеть покопать профайлер - но это долго, а понять хочу сейчас. По своему опыту - всегда отказываюсь от ВТ в пользу вложенного - если к ВТ есть только одно обращение. И ни разу не замечал сильных падений производительности.

+ На ИТС говорится единственно - что нужно по возможности отказываться от вложенного, ибо это негативно влияет на план запроса. Но я во имя читабельности этим обычно пренебрегаю - и повторюсь что сильных падений производительности не замечал.

нет правильного, увы

(2) а если версия скуля после обновления план начнет по другому строить? Вот тут же периодически приходят с вопросом о том, что скуль менять приходится и всем советуют mssql 2014

У вас сервер баз данных какой?

А так... в то, что вложенный запрос в левом соединении будет выполняться циклически... Не может такого быть - не верится в возможность автоматического составления такого плана запроса.

(4) На SQL. Только не знаю что-там-как-там - меня туда не пускают, да я и не лезу. Жаль конечно - нет возможности смотреть  в профайлер. Но я думаю на самом деле - тут даже не в плане выполнения зарыта собака. Есть же некий механизм, уже "зашитый"? Т.е. план - строит алгоритм по которому выполняется выборка данных, а сам-то этот алгоритм уже неизменен. Вот сам этот алгоритм я и хочу узнать - каков он если к основной таблицы левым соединением добавляется вложенный запрос. Мне кажется тут закопано нечто универсальное, неизменное...

(5) Блин, неверно выразился. Не "строит алгоритм", а выбирает стратегию... Не хватает знаний матчасти, чтобы выразиться четко)

ап

Просто для себя добавлю выдержку из ИТС:
"Оптимизатор сервера СУБД (независимо от того, какую СУБД вы используете) не всегда может правильно оптимизировать подобный запрос. В данном случае, проблемой для оптимизатора является выбор правильного способа соединения. Существуют несколько алгоритмов соединения двух выборок. Выбор того или иного алгоритма зависит от того, сколько записей будет содержаться в одной и в другой выборке. В том случае, если вы соединяете две физические таблицы, СУБД может легко определить объем обоих выборок на основании имеющейся статистики. Если же одна из соединямых выборок представляет собой вложенный запрос, то понять, какое количество записей она вернет, становится очень сложно. В этом случае СУБД может ошибиться с выбором плана, что приведет к катастрофическому падению производительности запроса."

https://its.1c.ru/db/v8std#content:-2145782992:hdoc

никакого циклического запроса, скуль не будет дочитывать данные. Цикл возможен в алгоритме соединения (8) (с) "В данном случае, проблемой для оптимизатора является выбор правильного способа соединения."

(8) ну тут можно на более примитивном уровне объяснить - если составлять запросы отдельными выборками внутри пакета, то каждая их них может быть оптимизирована статистикой СУБД с высокой вероятностью. Если же запрос содержит вложенные выборки внутри соединений, то оптимизация со стороны СУБД маловероятна.

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

(9)(10) Да это понятно все. Это по-сути следствие из (8). Но что именно SQL делает с вложенным, как именно его выполняет - это уже механика самого SQL, и понять это можно только долгим копанием профайлера.
Добавлю к (10) - мне приходилось работать с запросами, где разработчик настолько не был ленив, что высота закладки отображающей наименование ВТ была равна ~1мм (60 ВТ). Вот как вы считаете - что лучше: вложенный запрос и 3 закладки, или разбивать все на ВТ и 20 закладок?
Лично я используя консоль ИР с ее деревом всегда избавляюсь от ВТ (в случае ее однократного использования) преобразуя их в подзапросы, и параллельно мониторю падение производительности. Вот ни разу - на довольно больших выборках по полмиллиона строк - не замечал больших потерь. Предполагаю потому что сами запросы в ВТ были неоптимизированы (сложные условия в секции ГДЕ и т.п.)

(11) Предупреждая камни в огород: я знаю, что самое лучшее - это правильно спроектированная архитектура, но отталкиваемся от того, что есть)

(12) да мы просто говорим об этой проблеме с разных позиций. Я в запросах про мягкое, а не про теплое.

Если хочется говорить о том, что имеется куча причин к медленной работе вложенных запросов - так это действительно так. Вполне вероятно, что на типовых конфигурациях, как раз в силу оптимального проектирования данных, эти причины к замедлению встречаются нечасто. Но порой бывает достаточным влепить в запрос В ИЕРАРХИИ и тормоза внезапно возникают. В СКД ключевое слово В ИЕРАРХИИ не используется. Но скрытые механизмы, способные вызвать такой же эффект, тем не менее остаются.

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

(11) В ИР 3.60 значительно улучшены возможности преобразования подзапросов во временные таблицы и обратно