DISTINCT и GROUP BY в SQL: что выбрать для уникальных значений

Коротко

Выбирай DISTINCT, когда правило уникальности понятно. Выбирай GROUP BY, когда результатом являются группы и агрегаты. Для качества данных сначала показывай дубли отдельным запросом, а не сразу удаляй их в финальном отчёте.

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

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

DISTINCT оставляет уникальные комбинации выбранных колонок. GROUP BY формирует группы и нужен, когда нужно посчитать, суммировать или вычислить другие агрегаты. Запросы иногда дают одинаковый результат, но различаются намерением и возможностью расширения.

Для списка пользователей, открывших экран, DISTINCT user_id уместен, если событие может повторяться. Для проверки дублей сначала посчитай COUNT(*) и COUNT(DISTINCT event_id) по ключу. Для выручки нельзя использовать DISTINCT amount: два одинаковых заказа — не дубликаты только потому, что суммы совпали.

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

Перед DISTINCT назови ключ уникальности. Для событий это может быть event_id, user_id + event_name + occurred_at или отдельный idempotency key. Сравни количество строк до и после удаления, найди примеры повторов и реши, что делать с ними: оставить, дедуплицировать или исправить загрузку.

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

SELECT event_name, COUNT(*) AS rows_count,
       COUNT(DISTINCT event_id) AS unique_events,
       COUNT(DISTINCT user_id) AS users
FROM events
WHERE occurred_at >= TIMESTAMP '2026-07-01 00:00:00'
GROUP BY event_name
ORDER BY rows_count DESC;

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

Первый тест — арифметический: совпадает ли число строк с ожидаемым зерном, а сумма подгрупп с общей суммой? Второй — поведенческий: что происходит на пустой группе, 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, границы периода и стоимость. Иногда два запроса дают одинаковые цифры на текущем срезе, но один будет ломаться после появления повторного события или новой категории. Хорошее решение выдерживает не только текущий пример, но и заранее названные крайние случаи.

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

DISTINCT по всем колонкам не удалит строки, где отличается техническое поле. DISTINCT в агрегате меняет смысл: COUNT(DISTINCT user_id) считает людей, COUNT(*) — события. Не используй DISTINCT после подозрительного JOIN, пока не проверил кардинальность связи.

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

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

Выбирай DISTINCT, когда правило уникальности понятно. Выбирай GROUP BY, когда результатом являются группы и агрегаты. Для качества данных сначала показывай дубли отдельным запросом, а не сразу удаляй их в финальном отчёте.

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

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

Возьми таблицу событий и сделай аудит: число строк, уникальные event_id, пользователи, события по минутам. Найди случай, где один пользователь совершил одно действие несколько раз законно. Затем добавь дублирующую строку и проверь, как меняется метрика.

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

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

Вывод

Выбирай DISTINCT, когда правило уникальности понятно. Выбирай GROUP BY, когда результатом являются группы и агрегаты. Для качества данных сначала показывай дубли отдельным запросом, а не сразу удаляй их в финальном отчёте.

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