Ответ.

История вопроса:

Вложенные подзапросы изначально задумывались в SQL для расширения выразительных возможностей языка и решения сложных бизнес-задач, которые не укладываются в простые SELECT-операторы. Однако с ростом объёмов данных и сложностью реляционных моделей пришло понимание — не всегда вложенные подзапросы работают эффективно: многое зависит от реализации оптимизатора конкретной СУБД.

Проблема:

Основной вызов — найти компромисс между читаемостью, правильностью логики и производительностью. Не всегда вложенный подзапрос оптимизируется до join-операций, а часто превращается в дорогостоящие циклы перебора (Nested Loops).

Решение:

• Использовать вложенные подзапросы в SELECT для вычисления агрегатов или сложных выражений, если нельзя обойтись иначе.
• Для больших объёмов данных переходить на JOIN — это позволяет оптимизатору сделать запрос set-based и применить индексы.
• Вытаскивать подзапрос во внешнюю часть (через WITH/CTE), если нужно повысить читаемость или производительность.

Пример кода:

-- Вложенный подзапрос в SELECT (аккуратно!)
SELECT name, (SELECT COUNT(*) FROM orders WHERE orders.client_id = clients.id) AS order_count
FROM clients;

-- Эквивалент через JOIN (обычно быстрее):
SELECT clients.name, COUNT(orders.id) AS order_count
FROM clients
LEFT JOIN orders ON orders.client_id = clients.id
GROUP BY clients.name;

Ключевые особенности:

• Вложенные коррелированные подзапросы зачастую приводят к быстродействию O(N*M)
• Некоррелированные подзапросы — безопаснее и быстрее
• Вынос подзапроса в WITH/CTE или JOIN повышает предсказуемость плана и ускоряет исполнение

Вопросы с подвохом.

Работает ли вложенный подзапрос в SELECT быстрее, чем аналогичный LEFT JOIN?

Чаще — нет. Коррелированный подзапрос в SELECT исполняется для каждой строки внешнего запроса, тогда как JOIN строится один раз с индексами для всей таблицы.

Можно ли использовать подзапрос в FROM вместо CTE (WITH), и будет ли разница?

Да, подзапрос в FROM:**

SELECT t1.id, sub.agg
FROM table1 t1
JOIN (SELECT id, MAX(val) AS agg FROM table2 GROUP BY id) sub ON t1.id = sub.id;

Но CTE иногда обладает большей читаемостью и может приводить к другой оптимизации в планах выполнения.

Все вложенные подзапросы оптимизируются до аналогичных JOIN?

Нет. Не все СУБД умеют это делать одинаково, иногда вложенный подзапрос приводит к сканированию каждой строки, особенно если есть корреляция между внешним и внутренним запросом.

Типовые ошибки и анти-паттерны

• Использование вложенных коррелированных подзапросов в SELECT при больших объёмах.
• Дублирование условий фильтрации во внутреннем и внешнем запросе.
• Попытка заменить все вложенные подзапросы JOIN-ом без анализа задач.

Пример из жизни

Негативный кейс

Менеджер продаж сделал отчёт по клиентам, считая внутренним SELECT количество заказов. Времена выполнения — минуты, нагрузка на сервер росла в геометрической прогрессии.

Плюсы:

• Ясная логика Минусы:
• Очень медленный отчёт на большом количестве клиентов
• Неэффективная нагрузка на сервер

Позитивный кейс

Запрос переписали с LEFT JOIN и группировкой.

Плюсы:

• Выполнение за секунды
• Использование индексов Минусы:
• Более сложный GROUP BY и LEFT JOIN, требует понимания структуры данных