这是SQL标准强制要求的语义校验，因分组后非聚合字段在组内不唯一，数据库拒绝返回不确定结果；正确做法是将该字段加入GROUP BY或用聚合函数包裹。
GROUP BY后SELECT字段报错：column "xxx" must appear in GROUP BY clause
这是现代SQL引擎（MySQL 8.0+、PostgreSQL、SQL Server严格模式）的默认行为，不是bug，是语义强制校验。当你写 SELECT name, COUNT(*) FROM users GROUP BY age，数据库会直接拒绝执行，并抛出类似错误：column "name" must appear in the GROUP BY clause or be used in an aggregate function。
原因很实在：分组后每组对应多行原始数据，name 在同一 age 组里可能有多个值（比如两个25岁的人分别叫“张三”和“李四”），此时数据库无法确定该返回哪一个 name —— 返回任意一个都不可靠，也不可重现。
- 这不是“数据库太死板”，而是SQL标准（SQL:2003起）要求结果必须确定（deterministic）
- 旧版MySQL（5.6及之前）默认允许这种写法，但实际返回的是“组内第一行的
name”，行为隐式且不可控 - PostgreSQL 完全不妥协，从不提供“隐式 ANY_VALUE”兜底
- 即使你肉眼确认某字段在组内“总是相同”（如
user_id和email一一对应），数据库也不会自动推断函数依赖，必须显式声明
哪些字段能直接出现在SELECT中？只两类
分组查询的 SELECT 列表里，每个非聚合字段必须满足以下其一：
- 是
GROUP BY子句中明确列出的列（或表达式），例如GROUP BY user_id, DATE(created_at)→ 那么user_id和DATE(created_at)可直出 - 被包裹在聚合函数中，例如
MAX(name)、STRING_AGG(name, ',')、ANY_VALUE(name)（MySQL特有，慎用） - 注意：
SELECT中的别名不能用于GROUP BY，必须写原始列名或表达式；GROUP BY中也不能用聚合函数
反例：SELECT id, name, SUM(amount) FROM orders GROUP BY user_id —— id 和 name 都未分组也未聚合，必然报错。
ORDER BY 引用未分组字段也会失败
很多人以为只有 SELECT 受限，其实 ORDER BY 同样受约束。写 GROUP BY user_id ORDER BY name 会触发同样报错，因为排序目标 name 在组内不唯一，数据库无法定义“这组该排在哪”。
- 正确做法：把
name加入GROUP BY（变成按user_id, name分组），或改用聚合排序，如ORDER BY MAX(name) - 特别注意：MySQL 5.7+ 默认启用
sql_mode=ONLY_FULL_GROUP_BY，关掉它虽能绕过报错，但结果不可靠，生产环境不建议 - Access、SQLite 等轻量引擎行为更宽松，但这不代表写法正确——跨库迁移时大概率崩
容易被忽略的细节：NULL 和表达式
GROUP BY 对 NULL 值统一视为相同分组，这点常被低估。比如 GROUP BY category，所有 category IS NULL 的行会被归为一组，COUNT(*) 会包含它们，但 COUNT(category) 不会。
- 如果
GROUP BY中用了表达式（如YEAR(birth_date)），那么SELECT中若要引用年份，必须写完整表达式，不能写别名，也不能只写birth_date - 文本型字段（如
TEXT、MEMO）在多数数据库中不允许直接用于GROUP BY，Access 明确禁止，PostgreSQL 要先转成varchar截断 - 多字段分组时顺序影响结果可读性，但不影响逻辑正确性；不过若配合索引，顺序会影响性能
真正麻烦的从来不是语法报错本身，而是你以为“只是加个GROUP BY就能汇总”，却没意识到：分组不是压缩数据，是重新定义每一行的语义边界。一旦越界，数据库宁可报错，也不给你一个看似能跑、实则随时漂移的结果。
