SELECT列表中非聚合字段必须全部出现在GROUP BY中，否则数据库无法确定该取哪一行值，导致报错或结果不可靠；检查时需确保每个非聚合列（含表达式、别名）严格匹配GROUP BY列表。
SELECT列表里出现的非聚合字段必须全在GROUP BY中
因为数据库无法凭空决定“这一组里该取哪一行的值”。比如 SELECT name, department, COUNT(*) FROM employees GROUP BY department，每个部门可能有几十个name，name既没参与分组，也没被MAX()、GROUP_CONCAT()等函数处理，数据库只能报错——不是它不想选，是逻辑上不明确该选谁。
常见错误现象：ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause（MySQL 5.7+ 默认严格模式）或 ORA-00979: not a group by expression（Oracle）。
- 违反规则时，MySQL 5.7 以前可能“随机返回某一行的值”，结果不可靠且跨版本不一致
- PostgreSQL 和 SQL Server 基本都直接拒绝执行，不给模糊空间
- 即使某些数据库允许（如旧版 MySQL），
name的值也和COUNT(*)没逻辑关联——你看到的可能是组长姓名，也可能是实习生姓名
多字段分组时漏掉任意一个，就等于改了分组逻辑
写 GROUP BY department, job_id 是在定义“什么算同一组”：只有部门和岗位都相同的记录才归为一组。如果 SELECT 里写了 manager_id 却没放进 GROUP BY，那相当于要求数据库从“技术部-前端工程师”这组里，再按 manager_id 拆出不同子集，但它没收到这个指令。
使用场景：统计各城市各门店的销售额，但漏写 store_id —— 结果变成“上海所有门店销售额加总”，而不是“上海每家门店分别统计”。
- 检查方法：把
SELECT中每个非聚合列，逐个对照是否出现在GROUP BY列表中（顺序无关，但拼写和表达式必须完全一致） - 特别注意别名：不能用
SELECT dept_name AS d FROM t GROUP BY d，得写GROUP BY dept_name - 表达式要镜像：若
SELECT TRIM(LOWER(city))，GROUP BY也得是TRIM(LOWER(city))，不能只写city
聚合函数不是万能解药，得看你要什么语义
加 MAX(name) 或 GROUP_CONCAT(name) 能让语法通过，但不等于解决了业务问题。比如统计“每个班级最高分学生姓名”，用 MAX(name) 返回的是字典序最大的名字，不是考最高分那个人的名字。
性能与语义常冲突：用 GROUP_CONCAT(name ORDER BY score DESC LIMIT 1) 可能慢；用窗口函数 FIRST_VALUE(name) OVER (PARTITION BY class ORDER BY score DESC) 更准，但不是所有数据库都支持。
-
COUNT(*)、SUM()、AVG()这类数值聚合基本无歧义 -
MIN()/MAX()对字符串/日期有明确排序含义，但未必符合业务预期（比如取最新订单的客户名，MAX(order_date)可行，MAX(customer_name)不可行） - 想取“组内某行完整记录”，本质已超出
GROUP BY能力范围，该用窗口函数或关联子查询
ORDER BY 和 GROUP BY 的顺序不是执行顺序
GROUP BY 确实先于 SELECT 执行，但 ORDER BY 是最后一步——它排的是聚合后的结果集，不影响分组过程本身。有人误以为 “先 ORDER BY 再 GROUP BY 就能控制 MAX() 取哪条”，这是错的。
真正影响聚合行为的是 WHERE（分组前过滤）和 HAVING（分组后过滤）。比如想查“平均薪资超 15k 的部门”，必须用 HAVING AVG(salary) > 15000，写在 WHERE 里会报错。
-
ORDER BY中可以用GROUP BY字段或聚合结果（如ORDER BY COUNT(*) DESC），但不能用未出现在SELECT中的原始列 - 某些数据库（如 MySQL）允许
ORDER BY引用SELECT列别名，但标准 SQL 不保证这点，跨库迁移时容易出问题 - 分组键的 NULL 值会被视为相同——所有
department IS NULL的记录自动归为一组，这点常被忽略
MAX() 或隐式选取开始返回错误关联值，而你根本没意识到。 
