Порядок выполнения SQL-запроса: почему WHERE не видит alias из SELECT

Коротко

Если вопрос касается отдельных записей, начинай с WHERE. Если он касается результата агрегирования, используй HAVING. Если alias нужен для фильтра или повторного расчёта, подними вычисление на уровень CTE. Такая схема превращает порядок SQL в рабочую карту, а не в список исключений.

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

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

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

Допустим, нужно найти каналы с выручкой выше 100 000 ₽. WHERE работает со строками заказов до группировки, поэтому условие по SUM(revenue) появляется в HAVING. А псевдоним revenue_total создаётся только на шаге SELECT и не существует на этапе WHERE или HAVING в большинстве диалектов.

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

Перед исправлением запроса запиши зерно результата: одна строка — канал за месяц. Потом укажи, какие условия относятся к строкам, а какие к уже собранным группам. Если вычисление нужно использовать повторно, вынеси его в CTE или подзапрос. Так alias станет колонкой следующего отношения, а не магическим именем внутри текущего SELECT.

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

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

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

Не путай логический порядок с гарантированным физическим планом. Не рассчитывай на порядок строк без ORDER BY. Не используй HAVING для обычного фильтра по исходной таблице: это ухудшает читаемость и иногда увеличивает объём работы. И помни, что оконная функция вычисляется после группировки, поэтому её нельзя бездумно ставить в WHERE того же уровня.

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

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

Если вопрос касается отдельных записей, начинай с WHERE. Если он касается результата агрегирования, используй HAVING. Если alias нужен для фильтра или повторного расчёта, подними вычисление на уровень CTE. Такая схема превращает порядок SQL в рабочую карту, а не в список исключений.

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

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

Возьми отчёт по заказам и перепиши его в два шага: сначала CTE с дневной выручкой, затем внешний SELECT с фильтром и сортировкой. Отдельно подпиши, где находятся фильтры строк, фильтры групп и логика представления. Это простая привычка, которая заметно снижает число ошибок в больших запросах.

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

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

Вывод

Если вопрос касается отдельных записей, начинай с WHERE. Если он касается результата агрегирования, используй HAVING. Если alias нужен для фильтра или повторного расчёта, подними вычисление на уровень CTE. Такая схема превращает порядок SQL в рабочую карту, а не в список исключений.

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