IN и EXISTS в SQL: как проверять принадлежность и наличие связанных строк

Когда нужен этот приём

Когда использовать IN, а когда EXISTS для проверки связанной записи?

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

Логика оператора

IN сравнивает значение с набором значений. EXISTS проверяет, возвращает ли коррелированный подзапрос хотя бы одну строку и может остановиться после первого совпадения. Современный оптимизатор иногда превращает их в похожий semi-join, поэтому не стоит обещать, что один оператор всегда быстрее.

Определи, сравниваешь ли ты значение со списком или проверяешь связь между сущностями. Если связь one-to-many и нужна только проверка факта, начни с EXISTS. Для NOT EXISTS отдельно протестируй строки с NULL и пустые наборы.

• Зафиксируй одну строку результата.
• Отдели условия по исходным строкам от условий по рассчитанным значениям.
• Назови период, ключи связи и правило для повторов.

Рабочая версия

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

SELECT u.user_id
FROM users u
WHERE EXISTS (
  SELECT 1 FROM orders o
  WHERE o.user_id = u.user_id
    AND o.status = 'paid'
    AND o.paid_at >= DATE '2026-07-01'
);

Как сверить ответ

Собери пять-десять строк, где ответ можно получить вручную. Добавь NULL, дубль, объект без связанной записи и значение на границе периода. Затем сравни число строк и уникальных ключей до и после спорного шага.

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

Когда выбрать другой способ

NOT IN с NULL — классическая ловушка трёхзначной логики. IN (subquery) не означает JOIN и не даёт колонки второй таблицы. EXISTS не возвращает поля подзапроса. Не делай SELECT DISTINCT после JOIN только для имитации EXISTS.

IN подходит для понятного небольшого списка. EXISTS — для факта связанной строки. Для отрицательной проверки предпочитай NOT EXISTS, если в данных возможен NULL. Скорость подтверждай EXPLAIN ANALYZE на реальном объёме.

Небольшой эксперимент

Напиши два отчёта: пользователи с оплатой и пользователи без оплаты. Сгенерируй случай с двумя оплатами и NULL в справочнике. Сравни IN, EXISTS, NOT IN и NOT EXISTS и объясни результат словами, а не только ссылкой на план.

• Сначала запиши ожидаемый результат словами.
• Проверь запрос на маленькой контрольной выборке.
• Объясни, что запрос считает и чего не доказывает.

Следующий шаг

IN подходит для понятного небольшого списка. EXISTS — для факта связанной строки. Для отрицательной проверки предпочитай NOT EXISTS, если в данных возможен NULL. Скорость подтверждай EXPLAIN ANALYZE на реальном объёме.