UNION и UNION ALL в SQL: как объединять результаты запросов

Коротко

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

• Определи зерно результата до написания оператора.
• Разделяй фильтрацию строк, групп и рассчитанных показателей.
• Проверь NULL, дубли, границы периода и стабильность сортировки.
• Сверь запрос на маленьком примере перед публикацией метрики.

Какую задачу решает этот оператор

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

Если нужно собрать события из web_events и app_events, добавь source и используй UNION ALL. Если объединяются справочники с возможным пересечением и нужна уникальная пара code/name, UNION может быть оправдан. Но даже тогда документируй, почему дубликат считается одной сущностью.

Рабочий пример для аналитика

Сначала выровняй схему: одинаковые имена через alias, явные CAST и источник строки. Проверь зерно каждого набора. После объединения посчитай строки, уникальные ключи и пересечения по периодам. Не используй SELECT *: изменение схемы одной таблицы может сломать контракт.

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

SELECT user_id, event_name, occurred_at, 'web' AS source
FROM web_events WHERE occurred_at >= DATE '2026-07-01'
UNION ALL
SELECT user_id, event_name, occurred_at, 'app' AS source
FROM app_events WHERE occurred_at >= DATE '2026-07-01';

Как проверить результат

Первый тест — арифметический: совпадает ли число строк с ожидаемым зерном, а сумма подгрупп с общей суммой? Второй — поведенческий: что происходит на пустой группе, NULL, повторном событии и границе периода? Третий — сравнительный: можно ли получить тот же результат независимым способом на небольшом срезе?

Не ограничивайся тем, что запрос выполнился. Рабочий SQL должен быть объяснимым: другой аналитик понимает источник, фильтр, связь и причину выбранного оператора. Если результат меняется после добавления строки, зафиксируй, какое бизнес-правило это объясняет.

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

Зерно данных и границы расчёта

До запуска запроса выпиши, что означает одна строка в каждой таблице. В orders это может быть заказ, в order_items — позиция заказа, а в events — отдельное событие. Оператор работает поверх этого зерна: если соединить таблицы разных уровней без промежуточной агрегации, сумма и количество начнут отвечать уже на другой вопрос.

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

Проверка на маленьком наборе

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

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

От запроса к рабочему решению

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

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

Как читать чужой SQL-запрос

Начинай не с отдельных операторов, а с внешнего результата. Найди SELECT, посмотри, какие поля группируются, затем поднимись к FROM и JOIN. У каждого источника подпиши примерное зерно и ожидаемую кардинальность связи. После этого проверь WHERE: он может убрать пользователей до расчёта, а может незаметно исключить строки, которые нужны для знаменателя.

Если в запросе есть CTE, читай их сверху вниз и фиксируй, что изменилось на каждом шаге: только названия, число строк, зерно или бизнес-смысл. Если есть окно, проверь PARTITION BY и ORDER BY. Если есть отрицательное условие, отдельно протестируй NULL. Такой порядок чтения помогает делать ревью по логике, а не спорить о стиле форматирования.

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

Что чаще всего ломается

UNION не заменяет JOIN: он добавляет строки, а не колонки. Порядок колонок важнее их имён. UNION может удалить реальные повторы. UNION ALL может удвоить период, если источники пересекаются. Даты и numeric-типы лучше приводить явно.

Отдельно проверь изменение зерна после JOIN или разворачивания массива. Большая часть странных цифр появляется не из-за сложного синтаксиса, а потому что одна строка стала описывать два разных факта. Полезный приём — временно вывести ключ и посчитать COUNT(*) по нему до и после спорного шага.

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

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

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

Мини-практика

Объедини web и mobile события за месяц с полем source. Затем добавь одну общую строку и сравни UNION с UNION ALL. В отчёте объясни, какой ключ отвечает за уникальность события и где должна происходить дедупликация.

После решения напиши короткое объяснение в формате: «одна строка результата — …; в числителе — …; знаменатель — …; период — …; потенциальное ограничение — …». Такой шаблон хорошо переносится в SQL-тренажёр, ревью и рабочий отчёт.

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

Вывод

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

Главный навык здесь — не выучить оператор, а увидеть уровень данных, на котором он работает. Когда вопрос, зерно и период зафиксированы, SQL становится воспроизводимым способом принять решение, а не набором случайных конструкций.