WHERE и HAVING в SQL: разница на примерах аналитики

Коротко

Используй WHERE для отбора исходных строк и HAVING для отбора результатов группировки. Если условие сложно объяснить одним предложением, сначала вынеси промежуточный слой в CTE. Хороший SQL показывает не только ответ, но и уровень, на котором он получен.

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

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

WHERE убирает исходные строки до GROUP BY. HAVING фильтрует уже собранные группы и может использовать агрегаты COUNT, SUM или AVG. Чем раньше отфильтрованы ненужные строки, тем меньше данных проходит дальше. Поэтому условие по исходному столбцу обычно стоит в WHERE.

Для выручки канала сначала оставь только оплаченные заказы за период через WHERE. После GROUP BY посчитай SUM(amount), а затем HAVING revenue > 500000. Если поставить status = paid в HAVING, читателю сложнее понять зерно, а база может сначала построить больше групп.

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

Опиши результат одной фразой: «одна строка — канал за месяц». Затем раздели фильтры на две корзины: фильтры событий и фильтры агрегата. Проверь знаменатель: удаление строк WHERE меняет и числитель, и базу для последующей агрегации. Для сложных выражений используй CTE.

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

SELECT channel, COUNT(*) AS orders_count, SUM(amount) AS revenue
FROM orders
WHERE status = 'paid' AND paid_at >= DATE '2026-07-01'
GROUP BY channel
HAVING COUNT(*) >= 100 AND SUM(amount) >= 500000
ORDER BY revenue 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, границы периода и стоимость. Иногда два запроса дают одинаковые цифры на текущем срезе, но один будет ломаться после появления повторного события или новой категории. Хорошее решение выдерживает не только текущий пример, но и заранее названные крайние случаи.

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

HAVING без GROUP BY иногда допустим для одной общей группы, но это не делает запрос понятнее. Не переноси фильтр по дате из WHERE в HAVING. Не фильтруй SUM после округления, если порог чувствителен. И не сравнивай результаты двух запросов, если в одном WHERE исключает отмены, а в другом нет.

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

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

Используй WHERE для отбора исходных строк и HAVING для отбора результатов группировки. Если условие сложно объяснить одним предложением, сначала вынеси промежуточный слой в CTE. Хороший SQL показывает не только ответ, но и уровень, на котором он получен.

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

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

Составь четыре запроса: товары с price > 1000, категории с COUNT(*) > 50, каналы с SUM(amount) выше порога и сегменты с AVG(order_value) ниже медианы. Для каждого подпиши, на каком уровне живёт условие. Затем сравни число обработанных строк.

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

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

Вывод

Используй WHERE для отбора исходных строк и HAVING для отбора результатов группировки. Если условие сложно объяснить одним предложением, сначала вынеси промежуточный слой в CTE. Хороший SQL показывает не только ответ, но и уровень, на котором он получен.

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