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

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

Это отличается от обычного JOIN, которому могут потребоваться все совпадения, а затем устранение дубликатов. Однако конкретный план зависит от оценок кардинальности, стоимости операций и выбранного типа соединения.

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

В реляционной алгебре проверка существования имеет отдельную семантику: результат содержит строку внешней таблицы не более одного раза, независимо от количества совпадений во внутренней. Представление такой операции как semi join позволяет оптимизатору не строить полный набор совпадений там, где нужен только ответ «есть» или «нет».

Индекс по внешнему ключу решает исходную практическую проблему — поиск заказов для конкретного клиента без полного сканирования таблицы orders.

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

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

Даже при EXISTS индекс не гарантирует быстрый запрос: клиентов может быть очень много, условие может быть малоселективным, а оптимизатор может предпочесть hash join или полное сканирование. Поэтому важно понимать не только наличие индекса, но и форму операции и оценки стоимости.

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

Для каждого кандидата из customers оптимизатор может выполнить индексный поиск по orders.customer_id. Как только найдена первая запись с нужным customer_id, проверка считается успешной; остальные заказы этого клиента читать не требуется.

Логически это можно представить так:

CREATE INDEX ix_orders_customer_id
    ON orders (customer_id);

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

На практике возможен план Nested Loops с внутренним Index Seek и ранним прекращением поиска после первого совпадения. Но оптимизатор вправе выбрать другой план: например, один раз просканировать orders, построить структуру найденных ключей и соединить её с customers. Это бывает выгоднее, если внешних строк много или большинство клиентов имеют заказы.

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

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

Отчёт выводит активных клиентов, у которых есть заказы. Вариант через JOIN возвращает множество повторяющихся идентификаторов клиентов, поэтому разработчик добавляет DISTINCT. Вариант с EXISTS сразу выражает требуемую семантику и позволяет плану завершать поиск после первого совпадения по индексу.

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

Предпочтительное решение — оставить оптимизатору выбор, создать индекс по orders.customer_id, проверить фактический план и сравнить число логических чтений. Если индексный план применяется для малого числа клиентов, он обычно выигрывает благодаря раннему завершению; для массовой выборки может быть выбран другой, более подходящий план.

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

1. Гарантирует ли EXISTS всегда обращение только к первой строке?

Нет. EXISTS задаёт логическую семантику существования, но физический план может сначала полностью обработать внутреннюю таблицу, например построить хеш-структуру. Ранний выход характерен для плана с итерационной проверкой вроде nested loop, но не является обязательным свойством любого плана.

2. Почему индекс по orders.customer_id может не дать ускорения?

Если нужно проверить почти всех клиентов, а подходящие заказы есть у большинства, множество отдельных индексных поисков может стоить дороже последовательного чтения orders. На решение влияют селективность, объём таблиц, стоимость случайного доступа, видимость данных в кэше и точность статистики.

3. Чем EXISTS отличается от IN с точки зрения этого механизма?

При корректной обработке NULL оптимизатор часто способен преобразовать IN и EXISTS в близкие или одинаковые полусоединения, но это не универсальная гарантия. Семантика NOT IN особенно отличается: наличие NULL во внутреннем результате может привести к результату UNKNOWN, поэтому для проверки отсутствия обычно безопаснее рассматривать NOT EXISTS и отдельно анализировать условия.