Как правильно делать агрегацию в SQL

Что проверяют

Понимаете ли вы логический порядок выполнения запроса и где агрегация тихо даёт неверные цифры. Типичные уточнения: чем WHERE отличается от HAVING, как NULL влияет на AVG и почему после JOIN выросла сумма.

Как отвечать

Начните с порядка: FROM и JOIN, затем WHERE, GROUP BY, HAVING, SELECT вместе с оконными функциями, DISTINCT, ORDER BY, LIMIT. Из него следуют правила:

• WHERE против HAVING: WHERE фильтрует строки до группировки, HAVING группы после. Условия на обычные поля пишите в WHERE, тогда в группировку попадёт меньше строк;
• поля в SELECT: каждая неагрегированная колонка должна быть в GROUP BY или функционально зависеть от первичного ключа из него. В MySQL начиная с 5.7 по умолчанию включён ONLY_FULL_GROUP_BY, и старые запросы с «лишними» колонками перестают работать;
• NULL: все агрегаты, кроме COUNT(*), их пропускают. AVG(col) и AVG(COALESCE(col, 0)) дают разные числа, а SUM по одним NULL возвращает NULL, а не 0;
• условная агрегация: несколько метрик за один проход через COUNT(*) FILTER (WHERE status = 'paid') в PostgreSQL или SUM(CASE WHEN ... THEN 1 ELSE 0 END) в любом диалекте;
• детали рядом с итогом: если нужны исходные строки и сумма по группе одновременно, это оконная функция SUM(amount) OVER (PARTITION BY client_id), а не GROUP BY;
• подытоги: GROUPING SETS, ROLLUP и CUBE дают итоги по нескольким разрезам одним запросом.

Где спотыкаются

Агрегируют после соединения «один ко многим». Заказ с пятью позициями после JOIN превращается в пять строк, и SUM(order_total) умножается на пять. Сначала агрегируйте детальную таблицу в подзапросе или CTE, потом соединяйте.

Считают среднее от средних: средний чек по регионам, усреднённый ещё раз, не равен среднему чеку по всем заказам, потому что у регионов разное число заказов. Нужна взвешенная формула SUM(amount) / COUNT(*) по исходным строкам.

Делят целые на целые. В PostgreSQL COUNT(*) FILTER (...) / COUNT(*) для доли даёт 0, нужно привести одну из частей к numeric или умножить на 1.0.