非聚合字段未出现在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 的语义边界非常硬——它只负责“按字段切组+聚合”，不负责“组内择优”。一旦混淆这两层意图，后续维护和排查成本会指数上升。
