MySQL 5.7+ 报错“Expression #1 of SELECT list is not in GROUP BY clause”是因默认启用ONLY_FULL_GROUP_BY模式，强制要求SELECT中每个非聚合列必须出现在GROUP BY子句中或被聚合函数包裹，以符合SQL标准、防止语义不确定；直接补字段进GROUP BY可能引发逻辑错误，推荐优先使用窗口函数（如ROW_NUMBER()）或显式聚合函数确保结果确定、跨库兼容。
MySQL 5.7+ 默认执行 SQL 标准，不是 bug 是保护机制
报错 Expression #1 of SELECT list is not in GROUP BY clause 不是因为你漏写了逗号或拼错了字段名，而是 MySQL 主动拦住了语义模糊的查询。从 5.7.5 开始，ONLY_FULL_GROUP_BY 被默认启用，它强制要求：SELECT 中每个未被聚合函数包裹的列，必须显式出现在 GROUP BY 子句中。这不是 MySQL 自创的规则，是 SQL92 标准的硬性规定——分组后每组可能有 N 行，数据库无法凭空决定该返回哪一行的 name 或 email。
直接加字段进 GROUP BY 可能引入逻辑错误
看似最简单的解法是把报错字段补进 GROUP BY，但容易掩盖真实问题：
-
GROUP BY user_id, name在用户改过名、大小写混用、前后带空格时，会把同一user_id拆成多组，导致统计数虚高 -
GROUP BY created_at（毫秒级时间戳）几乎等于没分组，COUNT(*)变成行计数，失去聚合意义 -
name列含大量NULL时，所有NULL被归为一组，但业务上可能视其为“未填写”，这组就混杂了多种语义 -
DATE(created_at)在跨时区场景下切分不准：UTC 时间2026-06-05 00:10在东八区是 6 月 5 日上午 8:10，但按本地DATE()切可能变成 6 月 4 日
ANY_VALUE() 不是“随便取一个”，而是“我接受不确定性”
ANY_VALUE(name) 看似省事，但它不保证结果稳定：
- 同一查询多次执行，可能返回不同值——取决于是否启用并行扫描、索引是否覆盖、甚至 InnoDB 的页读取顺序
- 只存在于 MySQL 5.7.5+，PostgreSQL / SQL Server / Flink SQL 完全不识别，硬写进去迁移时直接报错
- 如果业务真正要的是“最新订单的用户名”，
ANY_VALUE(name)和MAX(name)都不对：MAX(name)是字典序最大，不是时间最新 - 云数据库（如阿里云 RDS）通常禁用
SET GLOBAL，你没法靠它临时绕过，只能重写 SQL
该用窗口函数而不是硬套 GROUP BY 的典型场景
当你需要“每组一条记录 + 原始明细字段”时，GROUP BY 就是反模式：
- 想查每个用户的最新订单完整信息（
order_id,status,amount,created_at），别写SELECT order_id, status, ... GROUP BY order_id——这必然报错，且就算关了ONLY_FULL_GROUP_BY，返回的status和created_at可能来自不同行 - 正确做法是用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)标记每组最新记录，再WHERE rn = 1 - PostgreSQL 可用
DISTINCT ON (user_id) ORDER BY user_id, created_at DESC，语义更紧凑 - 这种写法不依赖字段是否“实际一致”，也不怕
name有重复，逻辑清晰、结果确定、跨库可移植
