这是MySQL 5.7+默认启用ONLY_FULL_GROUP_BY模式导致的严格SQL标准校验：SELECT中每个非聚合字段必须显式出现在GROUP BY子句中或被聚合函数包裹，否则数据库无法确定分组内应返回哪一行值。

MySQL报错“xxx must appear in GROUP BY clause or be used in an aggregate function”是啥意思

这不是Bug，是MySQL在严格执行SQL标准：只要用了GROUP BY，SELECT里的每个字段，要么被MIN()、MAX()、COUNT()这类聚合函数包住，要么必须明明白白写进GROUP BY子句里。否则数据库根本不知道该返回分组内哪一行的值——比如SELECT name, age FROM users GROUP BY name，一个name对应多个age，取哪个？它拒绝猜。

为什么5.7+版本突然开始报错

因为MySQL默认启用了ONLY_FULL_GROUP_BY这个sql_mode。5.6及以前默认关着，允许“随便取一个值”，结果不可控；5.7起默认打开，强制你写出无歧义的SQL。

• 查当前模式：SELECT @@sql_mode;，如果里面含ONLY_FULL_GROUP_BY，就说明处于严格模式
• 它不只影响SELECT，也约束HAVING和ORDER BY里的非聚合列
• PostgreSQL、SQL Server、Oracle全都是默认严格模式，MySQL只是终于跟上了

SELECT里混了非聚合字段，怎么改才对

别急着关ONLY_FULL_GROUP_BY，先看业务到底要什么：

• 如果name和user_id是一对一（比如user_id是主键），而你GROUP BY user_id，却想顺手带出name——那就把name加进GROUP BY，或用MAX(name)（语义上等价，且可移植）
• 如果真需要“每组一条 + 原始明细字段”（如最新订单的用户姓名），GROUP BY不是正解，该用窗口函数：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC)再过滤
• ANY_VALUE(name)虽能绕过报错，但它不保证每次取同一行，也不被其他数据库支持，线上慎用

哪些细节容易被忽略导致改了还错

即使你把字段加进了GROUP BY，仍可能报错，常见隐形坑：

• 表别名不一致：比如SELECT t1.name但GROUP BY t2.name，哪怕指向同一列，生成SQL也会不匹配
• JOIN后误用关联表字段：用tableB.user_id分组，却SELECT tableA.name——没显式JOIN tableA，字段来源不明确
• NULL值被自动归为一组，但WHERE col IS NOT NULL漏写，统计口径就偏了
• 时间字段用TIMESTAMP vs DATETIME，时区处理差异可能导致分组结果意外合并或分裂

最稳妥的做法，是让GROUP BY基于主键或确定性唯一键，并确保SELECT中所有非聚合字段，要么是该键本身，要么能由它函数依赖推导出来——这点在跨库迁移或换ORM时特别关键。