SQL标准要求SELECT中非聚合列必须出现在GROUP BY中，否则因组内值不确定而报错；聚合函数列无需出现在GROUP BY中，且执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY。
报错是因为 SQL 标准要求：SELECT 列表中所有非聚合表达式必须出现在 GROUP BY 子句中——这不是 MySQL 的“脾气”，而是所有主流数据库（PostgreSQL、Oracle、SQL Server）共同遵守的语义底线。
GROUP BY 执行顺序决定报错必然性
SQL 实际执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。这意味着在走到 SELECT 阶段时，数据早已按 GROUP BY 分成若干组，每组只保留一行结果。如果 SELECT 里写了未聚合的字段（比如 name），数据库根本无法确定该取组内哪一行的 name 值——它不猜，直接拒。
- 错误示例：
SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id→name没分组也没聚合，必报ORA-00979或ERROR 1055 - MySQL 5.7+ 默认开启
ONLY_FULL_GROUP_BY，就是为堵住这种歧义 - PostgreSQL / Oracle / SQL Server 从不妥协，连解析都不通过
为什么 MAX(name) 或 ANY_VALUE(name) 能绕过？
这两种写法本质不同，但都满足“每组返回一个确定值”的前提：
-
MAX(name)是聚合函数，对组内所有name做字典序比较，结果确定、可复现 -
ANY_VALUE(name)是 MySQL 特有函数，声明“我接受不确定性”，但前提是业务上确认该字段在组内实际一致（如user_id和name是 1:1 关系） -
ANY_VALUE()不被其他数据库支持，迁移到 PG 或 Oracle 会直接失效
看起来能跑通，其实结果不可信
有些旧版 MySQL 或调低了 sql_mode，允许 SELECT user_id, name, SUM(amount) GROUP BY user_id 执行成功。但注意：name 和 SUM(amount) 极可能来自不同行——name 是随机挑的，SUM 是算出来的，二者无逻辑关联。
- 典型陷阱：你想查“每个用户的最新订单金额”，却写了
SELECT user_id, MAX(order_time), SUM(amount)→ 时间和金额根本不是同一笔订单 - 真需求应改用窗口函数：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC)，再过滤出序号 = 1 的行 - 视图里混用更危险：一旦创建成功，下游应用可能长期依赖这个“看似对、其实错”的逻辑
WHERE 和 HAVING 混用也会触发同类报错
聚合函数不能出现在 WHERE 中，因为 WHERE 在 GROUP BY 之前执行，此时聚合还没发生。
- 错误：
SELECT user_id FROM orders WHERE SUM(amount) > 1000→ 直接语法报错 - 正确：把条件移到
HAVING，且必须配合GROUP BY：SELECT user_id, SUM(amount) FROM orders GROUP BY user_id HAVING SUM(amount) > 1000 - 混淆
WHERE和HAVING是新手高频错误，本质还是没理清执行阶段
真正容易被忽略的是：报错只是表象，背后暴露的是对数据粒度和业务语义的理解偏差。你写的那列 name，到底代表什么？是分组标识？是组内单值？还是需要和聚合结果对齐的明细？先厘清这个，再选 GROUP BY、ANY_VALUE 还是窗口函数，而不是硬套语法让数据库“将就”。
