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

Да. Проверка принадлежности возвращает для строки внешнего запроса только факт наличия совпадения, поэтому повторные строки подзапроса не размножают результат. Обычное INNER JOIN сопоставляет строку с каждым совпадением, поэтому дубликаты в правой части могут увеличить число строк.

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

Подзапросы с проверкой принадлежности нужны для декларативного выражения условия «существует ли подходящая строка». Такая форма скрывает кратность совпадений: для результата важен сам факт наличия, а не количество найденных строк.

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

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

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

Ошибка особенно опасна при последующей агрегации: сумма, количество или другие агрегаты могут быть завышены. Добавление DISTINCT иногда маскирует проблему для простого списка, но не исправляет изменение кратности перед SUM, COUNT, LIMIT или оконными вычислениями.

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

Минимальный пример показывает различие семантики:

WITH clients(id) AS (
    VALUES (1)
), orders(client_id) AS (
    VALUES (1), (1)
)
SELECT c.id
FROM clients c
WHERE c.id IN (SELECT o.client_id FROM orders o);

SELECT c.id
FROM clients c
JOIN orders o ON o.client_id = c.id;

Первый запрос возвращает одну строку: клиент существует среди заказов. Второй возвращает две строки, поскольку одна строка клиента соединяется с двумя строками заказов.

Эквивалентной заменой обычно является EXISTS, когда столбцы правой стороны не нужны:

SELECT c.id
FROM clients c
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.client_id = c.id
);

EXISTS явно выражает проверку существования и не зависит от числа совпадений. Оптимизатор может реализовать её полусоединением и прекратить поиск по правой стороне после обнаружения первого подходящего ряда, хотя конкретный физический план зависит от СУБД и доступных индексов.

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

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

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

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

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

Выбран вариант с EXISTS, поскольку требовался только факт наличия оплаченного заказа. Он сохраняет одну строку клиента независимо от числа заказов, яснее передаёт намерение и обычно позволяет СУБД эффективно выполнить проверку по индексу на клиенте и статусе заказа.

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

Достаточно ли добавить DISTINCT после обычного соединения, чтобы сохранить эквивалентность?

Нет, не всегда. DISTINCT удаляет одинаковые итоговые строки только после выполнения соединения. Если до него применяются агрегаты, оконные функции, LIMIT, OFFSET или другие операции, изменённая кратность уже может повлиять на результат. Кроме того, если выбираются столбцы правой стороны, строки могут не быть одинаковыми и не удалятся.
Когда обычный JOIN всё-таки эквивалентен проверке существования?

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

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