这是语义问题而非语法错误，数据库因无法确定每组中非聚合列应取哪一行值而拒绝执行，如select user_id, name from orders group by user_id时，name可能有多个不同值，标准要求其必须出现在group by中或用聚合函数处理。
GROUP BY 报错 “column must appear in GROUP BY clause” 是语义问题，不是语法错误
数据库拒绝执行这条 SQL，并非因为写法不合法，而是它明确告诉你：这个查询逻辑上说不通。比如 SELECT user_id, name FROM orders GROUP BY user_id，一个 user_id 可能对应多条订单，name 值可能因历史改名、大小写混用、空格或 NULL 而不同。数据库没法决定该返回哪一行的 name —— 它不会替你猜，也不该替你猜。
PostgreSQL、SQL Server、Oracle 从不妥协，直接报错；MySQL 5.7+ 默认启用 ONLY_FULL_GROUP_BY 模式，只是把过去“静默容忍”的行为变成了显式拦截。
为什么不能默认取第一行或最新一行？
GROUP BY 不是排序或筛选操作，它是数据收敛（reduction）：把多行压缩成一行。WHERE 和 ORDER BY 不改变行数，而 GROUP BY 的目标是每组只输出一行结果。此时若允许未聚合列存在，等于默认假设“该列在组内所有行都相同”，但数据库不基于主键、外键或业务规则做这种推导——它只认语法结构。
- 即使
user_id是主键，SELECT user_id, status, created_at FROM logs GROUP BY user_id依然非法 -
MAX(created_at)只保证时间最大，不保证对应的status来自同一行 - 想取“每组最新一条完整记录”，
GROUP BY不是正解，该用窗口函数：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC)
补全 GROUP BY 字段看似简单，实际容易踩哪些坑？
把 name 加进 GROUP BY user_id, name 看似直白，但真实数据常让这一步失效：
-
name含前/后空格、大小写混用（如"Alice"和"alice"）会被分到不同组 -
name IS NULL会被单独归为一组，导致统计数虚高或漏掉 NULL 记录 - JOIN 后误用别名：
SELECT u.name却写GROUP BY users.name，字段来源不一致，生成 SQL 可能直接报错 - 时间字段如
created_at直接参与分组，跨时区或毫秒精度可能导致同一天的记录被切到不同组；要用DATE(created_at)就必须同步写进GROUP BY DATE(created_at)
ANY_VALUE() 不是万能解药，用错反而埋雷
ANY_VALUE(name) 是 MySQL 特有函数，作用是向数据库显式声明：“我知道这列在组内不唯一，我接受不确定性”。但它不保证每次取同一行值，也不被其他数据库支持。
- 在并发更新或优化器改写执行计划后，结果可能变化
- 如果业务真正依赖“最新状态”，用
ANY_VALUE(status)配合MAX(updated_at)会得到错配结果（最新时间 + 旧状态） - 云数据库（如阿里云 RDS）通常不允许直接
SET GLOBAL关闭ONLY_FULL_GROUP_BY，临时绕过不可靠
最易被忽略的一点：关掉 ONLY_FULL_GROUP_BY 后，MySQL 仍可能随机选值——这个“随机”取决于存储引擎、索引顺序、甚至查询缓存状态，根本不可控。
