非聚合字段未出现在group by中会报错，因数据库无法确定返回组内哪一行的值，属语义拒绝而非语法错误；如select department, name, count(*) from employees group by department，name未聚合也未分组，结果不可靠。

SELECT中非聚合字段没出现在GROUP BY里，为什么直接报错？

不是“必须包含”，而是数据库无法确定该返回哪一行的值——比如SELECT department, name, COUNT(*) FROM employees GROUP BY department，每个department组里可能有几十个name，name既没被聚合（如MAX(name)），也没参与分组，数据库不知道挑张三还是李四。这不是语法错误，是语义拒绝：结果不可靠，干脆不执行。

报错信息如ERROR 1055（MySQL）或ORA-00979（Oracle）就是明确告诉你：这个查询逻辑不自洽。

• PostgreSQL、SQL Server、Oracle 默认严格执行，不给模糊空间
• 旧版 MySQL（ONLY_FULL_GROUP_BY关闭时）会“随机选一个”，但这个值和COUNT(*)毫无业务关联
• 别指望主键能“自动推导”——MySQL 的 functional dependency 支持极有限，且版本敏感，生产环境别依赖

GROUP BY字段可以完全不出现在SELECT中，但要注意什么？

合法，比如SELECT COUNT(*) FROM sales GROUP BY region, year，region和year都没出现在SELECT里。这种写法常见于中间统计或嵌套子查询。

但实际用起来容易踩坑：

• BI 工具渲染图表时，缺少维度字段会导致“一堆数字不知对应哪组”
• 后续加HAVING或ORDER BY时，得把分组字段重新拉进SELECT，否则HAVING salary > 10000会报错（salary不在分组键里，也不是聚合结果）
• 调试时看到COUNT(*) = 5，却不知道这5条是来自华东2023年还是华北2024年——上下文丢失

表达式和别名在GROUP BY里不能偷懒

SELECT TRIM(LOWER(city)) AS city_clean FROM cities GROUP BY city是错的。GROUP BY 必须和 SELECT 中的表达式完全一致，不能用原始列名替代。

正确写法是：GROUP BY TRIM(LOWER(city))；别名city_clean也不能用于GROUP BY，GROUP BY city_clean会报错。

原因很简单：SQL 执行顺序是 FROM → WHERE → GROUP BY → SELECT，GROUP BY阶段city_clean这个别名还不存在。

• 多列组合表达式也一样，SELECT CONCAT(first_name, ' ', last_name) FROM users GROUP BY first_name, last_name ❌ 错，必须写成 GROUP BY CONCAT(first_name, ' ', last_name)
• 函数索引失效风险：在GROUP BY里用DATE(created_at)而不是直接分组created_at，可能导致无法走日期字段上的索引

加个MAX()就能过编译，但业务逻辑真对了吗？

用MAX(name)让查询通过，只是技术上绕过了限制，并不等于解决了问题。

比如你要查“每班最高分学生的姓名”，MAX(name)返回的是字典序最大的名字，不是分数最高的那个学生——这两者几乎从不重合。

• 真正需要的是窗口函数：ROW_NUMBER() OVER (PARTITION BY class ORDER BY score DESC)，再外层过滤
• 或者用关联子查询：WHERE score = (SELECT MAX(score) FROM students s2 WHERE s2.class = s1.class)
• GROUP_CONCAT(name ORDER BY score DESC LIMIT 1)（MySQL）或STRING_AGG(name, ',' ORDER BY score DESC LIMIT 1)（PostgreSQL）更贴近意图，但仍不如窗口函数清晰

最常被忽略的一点：GROUP BY 的语义边界非常硬——它只负责“按字段切组+聚合”，不负责“组内择优”。一旦混淆这两层意图，后续维护和排查成本会指数上升。