MySQL报错“Expression #1 of SELECT list is not in GROUP BY clause”是因5.7+默认启用ONLY_FULL_GROUP_BY模式，要求SELECT中非聚合字段必须出现在GROUP BY子句或套用聚合函数（如MAX、ANY_VALUE），否则语义不明确；推荐补全GROUP BY或用聚合函数显式表达意图，而非禁用该模式。
这不是语法写错，是数据库在拦你——它拒绝执行语义模糊的查询。
MySQL 报 “Expression #1 of SELECT list is not in GROUP BY clause” 怎么修
这是 ONLY_FULL_GROUP_BY 模式在起作用，不是 SQL 写错了，而是 MySQL 5.7+ 默认启用该模式，强制校验语义确定性。
- 典型错误：
SELECT user_id, name, SUM(amount) FROM orders GROUP BY user_id→name既没进GROUP BY，也没套聚合函数 - 最稳妥做法：补全
GROUP BY，比如GROUP BY user_id, name——但前提是业务上user_id → name确实是确定关系（如外键关联主表） - 若无法补全（比如
name可能变更），改用MAX(name)或ANY_VALUE(name)；注意ANY_VALUE()不保证结果稳定，换执行计划可能返回不同值 - 禁用
ONLY_FULL_GROUP_BY属于绕过检查：临时可SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,...'，但生产环境不推荐——它掩盖了逻辑歧义，PostgreSQL/Oracle 根本不支持这个选项
PostgreSQL / SQL Server / Oracle 报 “column must appear in GROUP BY clause” 怎么处理
这些数据库没有 ANY_VALUE()，也不接受“随便取一个”，报错就是硬性拦截，没商量余地。
- 必须显式聚合或重构逻辑：
MAX(created_at)、STRING_AGG(status, ',')（PostgreSQL）、LISTAGG(status, ',')（Oracle） - 如果分组字段是主键（如
id），那整行其实都可确定——此时不该硬套GROUP BY，该用窗口函数：ROW_NUMBER() OVER (PARTITION BY id ORDER BY created_at DESC)标记最新记录后过滤 - 别用子查询“先 GROUP 再 JOIN 回原表”，容易漏数据、重复、难维护
Flink SQL 或严格模式下 GROUP BY 字段类型不匹配导致分组异常
字符串和数字混用、NULL 处理差异、时区字段（如 TIMESTAMP vs DATETIME）都可能让分组结果出人意料。
-
GROUP BY CAST(user_id AS CHAR)和GROUP BY user_id在某些引擎下被当作不同分组逻辑 - 所有
NULL在GROUP BY中被归为同一组，但如果你加了WHERE col IS NOT NULL却忘了这点，统计口径就偏了 - 按
DATE(created_at)分组时，TIMESTAMP存 UTC、DATETIME存本地时间，跨时区数据可能被切到不同日期
真正棘手的不是报错本身，而是你以为加个 MAX() 就解决了，结果发现业务上要的是“最新一条的 status”，而 MAX(status) 是字典序最大——这种隐含语义偏差，只有在报表对不上时才暴露出来。
