GROUP BY и HAVING

Это единственная идея, которую нужно понять. Из неё следуют ответы на все остальные вопросы темы — почему агрегат не работает в WHERE, откуда берётся ошибка про GROUP BY и почему алиас из SELECT не виден в WHERE, но виден в ORDER BY.

Мы пишем запрос начиная с SELECT, а база выполняет его почти с конца:

Обрати внимание на пятый шаг. SELECT пишется первым, а выполняется предпоследним — поэтому алиас, заданный в нём, не существует на этапе WHERE, но прекрасно работает в ORDER BY.

Один запрос, восемь строк заказов и шесть стадий. Листай шаги и следи за подсветкой в запросе — она будет прыгать не сверху вниз, а по реальному порядку выполнения.

GROUP BY берёт строки и раскладывает их по корзинам: в одну корзину попадают строки с одинаковым значением в указанных колонках. Дальше каждая корзина превращается в одну строку результата.

Отсюда главное следствие: после группировки исходных строк больше не существует. Есть только группы и то, что можно про них посчитать.

-- ❌ ERROR: column "o.id" must appear in the GROUP BY clause
SELECT city, id, SUM(sum)
FROM orders
GROUP BY city;
-- в группе «Москва» три разных id — какой из них показать?

-- ✅ Вариант 1: добавить колонку в группировку
SELECT city, id, SUM(sum) FROM orders GROUP BY city, id;

-- ✅ Вариант 2: обернуть в агрегат — «покажи любой один»
SELECT city, MAX(id), SUM(sum) FROM orders GROUP BY city;

Группировка по нескольким колонкам

В GROUP BY можно перечислить несколько колонок — тогда группой считается уникальное сочетание их значений. GROUP BY city, status даст группы «Москва + paid», «Москва + cancelled» и так далее. Число групп при этом растёт быстро, поэтому разрезов лучше брать столько, сколько реально нужно в отчёте.

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

Разница между AVG = 15 и «средним по всем трём строкам» = 10 — ровно тот случай, когда отчёт выглядит правдоподобно и при этом неверен. Если пустое значение по смыслу означает ноль, его нужно заменить явно: AVG(COALESCE(v, 0)).

COUNT(DISTINCT …) — считаем уникальные

Отдельная форма для подсчёта уникальных значений. Именно так считают DAU: не число событий, а число разных пользователей.

SELECT
    event_date,
    COUNT(*)                    AS events,   -- сколько действий
    COUNT(DISTINCT user_id)     AS dau       -- сколько людей
FROM events
GROUP BY event_date
ORDER BY event_date;

NULL как отдельная группа

В обычных сравнениях NULL != NULL, но GROUP BY — исключение: все строки с пустым значением попадают в одну общую группу. В результате появится строка, где вместо названия группы стоит NULL. Если она не нужна, отсекай её до группировки через WHERE city IS NOT NULL.

HAVING — это WHERE, приехавший на четыре шага позже. Он получает уже посчитанные группы и решает, какие из них оставить.

SELECT city, COUNT(*) AS orders, SUM(sum) AS revenue
FROM orders
WHERE status = 'paid'          -- фильтр строк: до группировки
GROUP BY city
HAVING SUM(sum) > 1000        -- фильтр групп: после
ORDER BY revenue DESC;         -- алиас виден: ORDER BY идёт после SELECT

Попытка написать WHERE SUM(sum) > 1000 закончится ошибкой, и теперь понятно почему: на шаге WHERE групп ещё нет, а значит, и суммировать нечего.

Задачи на том же наборе заказов, что и в интерактиве выше.