Данные не лежат просто так
Каждый раз, когда ты открываешь ленту, алгоритм за долю секунды обрабатывает миллионы сигналов: что ты досмотрел, что промотал, на чём завис. Это не магия машинного обучения в вакууме — это запросы к базе данных, которые группируют, считают и сортируют поведение пользователей.
И в самом центре этой механики — оператор, который большинство новичков считают скучным: GROUP BY.
Один вопрос, который меняет всё
Представь: ты аналитик стартапа. Продукт вырос, данные есть, но инвестор задаёт простой вопрос:
«Из каких городов у нас больше всего активных пользователей?»
У тебя — таблица с миллионом строк. Каждая строка — один пользователь. Смотреть руками? Строить Excel вручную?
Вот что происходит вместо этого:
SELECT city, COUNT(*) AS user_count
FROM users
GROUP BY city
ORDER BY user_count DESC;
Три секунды — и ты знаешь всё. Это и есть GROUP BY: ты говоришь базе данных, как сгруппировать реальность, и получаешь картину мира.
Как это работает внутри
База данных берёт все строки и собирает их в кучки по значению указанного поля. Москва — одна кучка, Казань — другая, Самара — третья. Потом применяет к каждой кучке нужную функцию: посчитать, просуммировать, найти среднее.
Результат — одна итоговая строка на группу. Не миллион строк с пользователями, а чистая аналитика.
Именно так Spotify знает, что в Берлине слушают техно, а в Сеуле — k-pop. Именно так маркетплейс понимает, какие категории товаров тянут выручку, а какие — балласт.
Главное правило, которое все нарушают
Здесь есть ловушка, в которую попадают даже те, кто уже немного умеет писать запросы.
В SELECT можно указать только то, по чему группируешь, или то, что агрегируешь.
Никак иначе. Вот так — нельзя:
-- Ошибка: name не входит в GROUP BY
SELECT city, name, COUNT(*)
FROM users
GROUP BY city;
Почему? Потому что внутри группы «Москва» — сотни разных name. Какое из них вывести? База данных не угадывает — она требует чёткости. PostgreSQL честно скажет тебе об ошибке. MySQL в мягком режиме молча вернёт что попало — что ещё хуже.
Это не баг синтаксиса. Это философия реляционных данных: будь точен в том, что ты запрашиваешь.
WHERE и HAVING — не одно и то же
Ещё один момент, который разделяет тех, кто пишет запросы, и тех, кто понимает, как они работают.
WHERE — это фильтр до группировки. Ты отсекаешь строки ещё до того, как база начнёт считать.
HAVING — это фильтр после. Ты уже получил группы и теперь говоришь: «Оставь мне только те города, где пользователей больше ста».
SELECT city, COUNT(*) AS user_count
FROM users
WHERE created_at > '2024-01-01' -- сначала берём только новых
GROUP BY city
HAVING COUNT(*) > 100; -- потом оставляем только крупные города
Порядок имеет значение. И это не про синтаксис — это про логику того, как ты думаешь о данных.
Почему это важно прямо сейчас
Любой цифровой продукт — это, по сути, интерфейс над базой данных. Рекомендательная система, антифрод в финтехе, матчмейкинг в онлайн-игре, персонализация в e-commerce — везде в основе лежит агрегация и группировка данных.
Ты можешь не писать эти запросы сам каждый день. Но понимать, как они работают — значит понимать, как устроен цифровой мир вокруг тебя. А это уже другой уровень.
🔍 Хочешь копнуть глубже? Полный учебный материал с детальными примерами, схемами и иллюстрациями ждёт тебя на нашем сайте!