Краткий ответ

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

Если совпадений несколько, результат проверки не меняется: одно совпадение и сто совпадений одинаково дают TRUE. При этом оптимизатор может физически выполнить такую проверку через полусоединение или другой план, поэтому не следует воспринимать запрос как обязательный пошаговый перебор.

Исторический контекст

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

В SQL такая семантика нужна для выражения условий вида «у объекта есть связанная запись». Она позволяет отделить проверку существования от получения данных связанной таблицы.

Постановка проблемы

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

Удаление дублей через DISTINCT иногда исправляет видимый результат, но скрывает саму ошибку в выборе операции. Кроме того, DISTINCT может потребовать дополнительной сортировки или хеширования и не выражает намерение так ясно, как проверка существования.

Подробное решение

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

SELECT c.id
FROM customers AS c
WHERE EXISTS (
    SELECT 1
    FROM orders AS o
    WHERE o.customer_id = c.id
      AND o.status = 'paid'
);

SELECT 1 здесь не означает, что число 1 будет добавлено к результату. Для EXISTS список выбираемых выражений несущественен: важен сам факт наличия строки. Если найдено первое подходящее совпадение, логическая проверка уже может считаться успешной.

Корреляция задаётся условием o.customer_id = c.id: значение c.id берётся из текущей строки внешнего запроса. Без такого условия подзапрос был бы некоррелированным и его результат обычно был бы одинаковым для всех внешних строк.

Практический эффект — семантика полусоединения: из внешнего отношения сохраняются строки, для которых существует совпадение, но внутренние строки не добавляются к результату. Это не означает, что СУБД обязательно остановится буквально после чтения первой строки; оптимизатор может выбрать иной эквивалентный план, сохранив ту же семантику.

EXISTS также не зависит от значений, выбранных во внутреннем запросе. В частности, NULL в столбцах внутренней строки не мешает EXISTS вернуть TRUE, если сама строка удовлетворяет условию корреляции и другим предикатам. Однако если предикат внутри подзапроса вычисляется как UNKNOWN, такая строка не считается удовлетворяющей условию.

Ситуация из практики

В отчёте требовался список клиентов, у которых был хотя бы один заказ с просроченной оплатой. Вариант с соединением возвращал клиента по одному разу на каждый просроченный заказ, из-за чего последующая постраничная выборка показывала повторяющиеся идентификаторы.

Можно было применить соединение с DISTINCT. Его плюс — возможность одновременно выбрать атрибуты заказа; минусы — устранение дублей после их появления и потенциально более дорогой план. Можно было сгруппировать результат по клиенту, но это добавляло агрегацию, не нужную для исходной проверки.

Выбран был EXISTS, поскольку требовался только факт наличия заказа. Запрос стал напрямую отражать бизнес-условие, не создавал повторов клиентов и оставлял оптимизатору возможность использовать индекс по клиенту, статусу и другим селективным условиям.

Что кандидаты часто упускают

1. Чем EXISTS отличается от проверки COUNT(*) > 0?

EXISTS выражает проверку существования и не требует логически подсчитывать все совпадения. СУБД может завершить поиск после обнаружения подходящей строки или преобразовать запрос в полусоединение. COUNT(*) > 0 выражает агрегирование, поэтому такой вариант может быть менее подходящим для оптимизации, особенно если оптимизатор не выполнит эквивалентное преобразование.

2. Что изменится, если условие корреляции убрать?

Подзапрос перестанет зависеть от текущей строки внешнего запроса. Тогда EXISTS будет проверять один и тот же факт для всех внешних строк: существует ли вообще хотя бы одна строка, удовлетворяющая внутреннему фильтру. В результате либо пройдут все внешние строки, либо не пройдёт ни одна; выборочная проверка по каждому внешнему объекту исчезнет.

3. Можно ли заменить EXISTS на IN без изменения смысла?

Иногда да, если сравниваются эквивалентные ключи и корректно учтена семантика NULL. Но IN сравнивает значение с множеством значений и при наличии NULL в списке может дать UNKNOWN, тогда как EXISTS проверяет наличие строк и сам по себе не превращается в неопределённый результат из-за NULL в нерелевантном выбранном столбце. Поэтому механическая замена без анализа допускаемых NULL и условий корреляции небезопасна.