Краткий ответ

После GROUP BY несколько исходных строк превращаются в одну строку группы. Для неагрегированного столбца база данных должна однозначно определить единственное значение внутри этой группы; если значений несколько, выбор был бы произвольным. Поэтому такой столбец должен входить в группировку, быть аргументом агрегатной функции или быть однозначно функционально зависимым от ключа группы — если это поддерживает конкретная СУБД.

Исторический контекст

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

Требование согласованности выражений SELECT с группировкой защищает запрос от скрытого и недетерминированного выбора данных. Разные СУБД могут дополнительно распознавать функциональные зависимости, но переносимый SQL должен явно отражать гранулярность результата.

Постановка проблемы

Предположим, результат группируется по клиенту, но одновременно запрашивается город доставки. У одного клиента могут быть заказы из разных городов, поэтому после объединения строк непонятно, какой город должен попасть в итоговую строку.

Если СУБД молча выберет одно значение, результат может зависеть от плана выполнения, индексов или физического порядка строк. Если она отклонит запрос, это обычно полезнее: ошибка выявляет несоответствие между требуемым уровнем детализации и выбранными столбцами.

Подробное решение

Для каждой строки SELECT нужно определить её смысл после группировки:

столбец из GROUP BY описывает ключ группы;
агрегат, например COUNT, SUM, MIN или MAX, сворачивает множество значений в одно;
функционально зависимый столбец имеет единственное значение для каждого ключа группы, но возможность не указывать его явно зависит от СУБД и режима проверки.

Например:

SELECT customer_id, city, COUNT(*) AS order_count
FROM orders
GROUP BY customer_id;

Запрос некорректен в стандартном переносимом смысле: у клиента могут быть разные city. Исправление зависит от бизнес-смысла. Можно добавить city в GROUP BY, если нужны итоги по паре клиент–город, либо выбрать явное правило, например MIN(city), если это действительно осмысленная характеристика.

Важно отличать техническую допустимость от корректности результата. Агрегат MIN(city) устранит ошибку, но не сделает город главным или последним городом клиента; он лишь выберет лексикографически минимальное значение. Если требуется строка, соответствующая определённому заказу, сначала нужно формально определить критерий выбора, а затем решать задачу средствами оконных функций или другого детерминированного запроса.

Компромисс строгого режима очевиден: явные GROUP BY и агрегаты делают запрос длиннее, зато фиксируют ожидаемую гранулярность и уменьшают риск тихой ошибки. Послабления СУБД, основанные на функциональной зависимости, удобны, но хуже переносятся между системами и требуют понимания схемы данных.

Ситуация из практики

В отчёте нужно получить число заказов по клиентам, но разработчик добавил в SELECT имя менеджера. В большинстве случаев у клиента один менеджер, однако исторические данные содержат переassignments, поэтому для одного клиента встречаются разные менеджеры.

Рассматривались три варианта. Добавление менеджера в GROUP BY изменяло гранулярность и порождало несколько строк на клиента. Выбор MIN или MAX менеджера был простым, но мог показать неактуального сотрудника. Разрешение неагрегированного столбца через настройки СУБД скрывало неоднозначность и давало ненадёжный отчёт.

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

Что кандидаты часто упускают

1. Всегда ли столбец, отсутствующий в GROUP BY, запрещён?

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

2. Почему добавление спорного столбца в GROUP BY может изменить смысл отчёта?

GROUP BY задаёт гранулярность результата. Группировка только по клиенту создаёт одну строку на клиента, а группировка по клиенту и городу создаёт отдельную строку для каждой пары клиент–город; агрегаты после этого считаются уже внутри новых, более мелких групп. Поэтому добавление столбца — не только способ исправить синтаксическую ошибку, но и изменение бизнес-смысла результата.

3. Почему агрегат MIN или MAX не является универсальным исправлением?

Он действительно сводит несколько значений к одному и делает запрос формально однозначным, но выбранное значение определяется правилом MIN или MAX, а не требованием бизнеса. Для числовых показателей это может быть полезно, а для имени менеджера, статуса или адреса часто вводит в заблуждение. Перед применением агрегата нужно доказать, что именно такая свёртка имеет смысл, либо задать критерий выбора строки явно.