mysql 5.7+ 报错“expression #1 of select list is not in group by clause”是因默认启用only_full_group_by模式，要求select中所有非聚合字段必须出现在group by子句中；解决方法包括：修正sql（补全group by或用any_value()/聚合函数）、临时或永久修改sql_mode禁用该模式，但后者不推荐用于生产环境。
MySQL 5.7+ 报错 Expression #1 of SELECT list is not in GROUP BY clause 怎么办
这是 ONLY_FULL_GROUP_BY 模式在起作用，不是语法写错了，而是 SQL 标准在拦你。只要 SELECT 里出现了一个没被聚合、也没出现在 GROUP BY 中的字段，MySQL 就会直接拒绝执行。
常见错误写法：SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id → name 既没加进 GROUP BY，也没套 MAX() 或 ANY_VALUE()，必然报错。
- 最稳妥做法：把所有非聚合字段都补进
GROUP BY，比如GROUP BY user_id, name - 若确认
name和user_id是 1:1 关系（如外键关联主表），可用ANY_VALUE(name)—— 但注意它不保证结果稳定，换版本或优化器路径可能返回不同值 - 禁用
ONLY_FULL_GROUP_BY属于绕过校验，不是解决问题：临时改sql_mode只影响当前 session；永久改需编辑my.cnf并重启 MySQL，但会掩盖语义歧义，其他数据库（PostgreSQL/SQL Server）根本不给你这个选项
PostgreSQL / SQL Server 报错 column must appear in GROUP BY clause 怎么处理
这些数据库没有 ANY_VALUE()，也不接受“隐式取一行”，报错就是硬性拦截，没商量余地。
典型失败语句：SELECT id, status, created_at FROM logs GROUP BY id → status 和 created_at 都不确定选哪条记录的值。
- 必须显式聚合：比如用
MAX(created_at)、STRING_AGG(status, ',')（PostgreSQL）、STRING_AGG(status, ',' ORDER BY created_at DESC) - 如果
id是主键，那整行其实都可确定，此时不该用GROUP BY，而该用窗口函数，例如：SELECT DISTINCT ON (id) * FROM logs ORDER BY id, created_at DESC（PG）或ROW_NUMBER() OVER (PARTITION BY id ORDER BY created_at DESC)（通用） - 别试图用子查询“先 GROUP 再 JOIN 回原表”——容易漏数据或重复，逻辑一复杂就难维护
Flink SQL 中 is not being grouped 错误怎么修复
Flink SQL 同样遵循标准语义，SELECT a, b, c FROM t GROUP BY a, b 里 c 没分组也没聚合，就会报这个错。
- 加进
GROUP BY最简单，但要注意：如果c值离散度高（比如 UUID 或时间戳），会导致分组数爆炸，性能骤降 - 优先考虑聚合函数：用
LAST_VALUE(c) OVER (PARTITION BY a, b ORDER BY ts DESC)替代，前提是能明确排序依据（比如有ts字段） -
COLLECT_LIST(c)或ARRAY_AGG(c)可保留全部值，但下游得处理数组结构，不适合直出报表场景
为什么 GROUP BY 字段类型不匹配也会报错或结果异常
看起来没动 SELECT 和 GROUP BY 的字段组合，但结果为空、分组数不对、甚至报类型转换错误，很可能是字段隐式转换在捣鬼。
-
GROUP BY user_id和GROUP BY CAST(user_id AS CHAR)在某些引擎下视为不同分组逻辑，尤其当user_id是数字型但数据里混了字符串前缀时 -
NULL值全被归为同一组，但如果你在WHERE里写了col IS NOT NULL，又忘了GROUP BY本身对NULL的聚合行为，统计口径就偏了 - 时区字段要小心：
TIMESTAMP存 UTC，DATETIME存本地时间，用DATE(created_at)分组时，跨时区数据可能被切到不同日期 —— 这类问题不会报错，但结果不可信
真正麻烦的从来不是报错本身，而是你以为加个 ANY_VALUE() 或删掉 ONLY_FULL_GROUP_BY 就万事大吉；实际业务中，一个字段是否“逻辑上单值”，往往得翻表设计、查历史变更、看 ETL 流程才能确认。没理清这点，修完 SQL 也可能交出错误结果。
