mysql报“expression #1 of select list is not in group by clause”是因5.7+默认启用only_full_group_by模式，要求select中每个非聚合字段必须出现在group by子句中或被聚合函数包裹，否则拒绝执行以防止语义不确定。
这不是语法写错了，是 SQL 标准在拦你——SELECT 里每个没被聚合函数包裹的字段，要么进 GROUP BY，要么改用明确语义的替代方案。
MySQL 报 “Expression #1 of SELECT list is not in GROUP BY clause” 是什么情况
MySQL 5.7+ 默认启用 ONLY_FULL_GROUP_BY 模式，它强制校验：只要 SELECT 列表中出现非聚合字段（比如 name、email），它就必须出现在 GROUP BY 子句中，或被 MAX()、MIN()、ANY_VALUE() 等包裹。否则直接拒绝执行，连执行计划都不生成。
- 典型错误写法：
SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id→name既没进GROUP BY，也没套聚合函数 - 错误本质不是“数据库不会选”，而是“不该让数据库替你猜”：同一
user_id可能对应多个name（改名、多账户、脏数据），返回哪条？语义不明确 - PostgreSQL / SQL Server 报的错更直白：
column "name" must appear in the GROUP BY clause or be used in an aggregate function
为什么加个字段进 GROUP BY 还会出错或结果不对
看似补全了分组字段，但可能引入隐式语义偏差，导致统计失真或逻辑错位：
-
GROUP BY user_id, name在name存在大小写混用、前后空格、历史改名时，会让同一user_id被拆成多组，COUNT(*)虚高 - 时间类字段如
created_at（带毫秒）直接进GROUP BY，几乎等于没分组，COUNT(*)变成行计数 - 字符串字段含
NULL时，所有NULL被归为一组，但业务上可能把NULL视为“未填写”，这组就混杂了多种语义 - MySQL 中对
TIMESTAMP用DATE(created_at)分组，跨时区数据可能被切到错误日期（比如 UTC 时间 2026-06-05 00:10 在东八区是 6 月 5 日上午 8:10，但按本地DATE()切就变成 6 月 4 日）
ANY_VALUE() 真的能“随便取一个”吗
ANY_VALUE(name) 只是告诉 MySQL：“我接受不确定性”，但它不保证结果稳定或可复现：
- 同一查询多次执行，可能返回不同值——取决于优化器是否启用并行扫描、索引是否覆盖、甚至 InnoDB 的页读取顺序
- 它只存在于 MySQL 5.7.5+，PostgreSQL / SQL Server / Flink SQL 完全不识别，硬写进去迁移时直接报错
- 如果业务真正要的是“最新订单的用户名”，而你用了
ANY_VALUE(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有重复，逻辑清晰、结果确定、跨库可移植
最容易被忽略的一点：即使你成功让 SQL 跑通了，只要没搞清字段和分组键之间的函数依赖关系，报表数据就可能在某次数据变更后悄然出错——比如某天 user_id → name 不再是一对一，ANY_VALUE() 或补全 GROUP BY 都会放大这个偏差，而不是暴露它。
