这是SQL标准对语义明确性的强制要求：分组后非聚合列若未出现在GROUP BY中，数据库无法确定返回哪一行的值，故直接报错；MySQL 5.7+默认启用ONLY_FULL_GROUP_BY，PostgreSQL/SQL Server一贯严格。
GROUP BY 报错 “Expression not in GROUP BY clause” 是什么逻辑
这不是数据库故意为难你，而是 SQL 标准对语义明确性的强制要求：当数据被分组后，每个组对应多行原始记录，而 SELECT 中若出现一个既没参与分组、又没用聚合函数包裹的列（比如 name），数据库根本无法确定该输出哪一行的 name 值——它不猜，直接报错。
典型错误信息长这样：1055-Expression#1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'xxx'...。MySQL 5.7+ 默认开启 ONLY_FULL_GROUP_BY 模式，PostgreSQL 和 SQL Server 从一开始就这么严格。
- 检查当前模式：运行
SELECT @@sql_mode，确认是否含ONLY_FULL_GROUP_BY - 临时绕过（不推荐）：用
ANY_VALUE(name)包裹非分组列，但返回值不可控，上线前务必删掉 - 真正修复：要么把列加进
GROUP BY，要么明确用MAX(name)、MIN(name)等聚合函数表达意图
为什么不能让数据库“自动选一个值”
表面看，SELECT department, name FROM staff GROUP BY department 似乎只是想随便挑个员工名字代表部门，但实际会埋下三类隐患：
- 结果不可重现：同一查询在不同 MySQL 版本、不同执行计划下，
name可能来自任意一行，测试通过不代表生产稳定 - ORM 生成语句易失效：Django 或 SQLAlchemy 的
.values('department').annotate(...)若隐式依赖非确定性行为，升级后可能突然崩 - 与 NULL 交互出问题：如果某组里
name全是NULL，ANY_VALUE(name)返回NULL；但如果混有非空值，返回哪个完全随机
GROUP BY 多列时，哪些列可以不写进 SELECT
GROUP BY 列本身可以不出现在 SELECT 中，语法合法，但几乎没意义。例如：SELECT COUNT(*) FROM sales GROUP BY salesperson, region 会返回每组的计数，但你根本不知道这组对应的是 Alice + North 还是 Bob + South。
真正有用的组合是“分组键 + 聚合结果”，比如：
SELECT salesperson, region, SUM(amount) AS total FROM sales GROUP BY salesperson, region;
注意：GROUP BY salesperson, region 意味着所有 salesperson = 'Alice' 且 region = 'North' 的行被压成一行；此时 SELECT 中的 salesperson 和 region 是确定的，不会歧义。
HAVING 过滤时，列必须出现在 SELECT 或 GROUP BY 中吗
PostgreSQL 强制要求：HAVING 中引用的列，必须已出现在 SELECT 列表或 GROUP BY 子句中。MySQL 相对宽松，允许 HAVING region = 'North' 即使 region 没出现在 SELECT，但这种写法跨库迁移时大概率失败。
更关键的是：别指望 HAVING 能筛掉 NULL 分组——HAVING region IS NOT NULL 在 PostgreSQL 里非法，在 MySQL 里虽能跑，但逻辑上它是在聚合后过滤，而 NULL 已经被归为一组了。真要排除 NULL，得在 WHERE region IS NOT NULL 阶段就干掉。
最常被忽略的一点是：GROUP BY 的语义边界非常硬——它不是“排序辅助工具”，也不是“去重快捷方式”。一旦用了 GROUP BY，整条语句就进入了“分组-聚合”范式，所有列都必须在这个框架里找到明确归属，否则就不是语法问题，而是数据语义失控的开始。
