MySQL 8.0+ 严格执行 SQL 标准导致 GROUP BY 报错，根本原因是 SELECT 中非聚合字段必须出现在 GROUP BY 中；ANY_VALUE() 仅抑制报错但不保证结果稳定，窗口函数才是获取每组明细的正确方案。
MySQL 8.0 或 5.7+ 执行 GROUP BY 时突然报错 “Expression #1 of SELECT list is not in GROUP BY clause”，不是你 SQL 写错了，是 MySQL 开始严格执行 SQL 标准了——SELECT 里每个没被聚合函数包裹的字段，必须明确出现在 GROUP BY 子句中。
为什么加个字段进 GROUP BY 还会出错？
表面补全了分组字段，但实际可能引入语义偏差或性能陷阱：
- 字符串字段如
name含前后空格、大小写混用或历史改名，会导致同一user_id被拆成多组，统计数虚高 - 时间类字段（如
created_at）直接进 GROUP BY，因毫秒级精度几乎每行都不同，等效于没分组，COUNT(*)变成行计数 -
NULL值在 GROUP BY 中被统一归为一组，但业务上可能代表“未填写”“未知”“已删除”多种含义，强行分组会掩盖数据质量问题 - 跨时区场景下用
DATE(created_at)分组，UTC 时间2026-06-05 00:10在东八区是 6 月 5 日上午 8:10，但按本地DATE()切就变成 6 月 4 日，日期错位
ANY_VALUE() 真的能“随便取一个”吗？
它只是告诉 MySQL：“我接受不确定性”，但不保证结果稳定、可复现或跨版本一致：
-
ANY_VALUE(name)在同一查询中多次执行，可能返回不同值——取决于是否启用并行扫描、索引是否覆盖、甚至 InnoDB 页读取顺序 - 只存在于 MySQL 5.7.5+，PostgreSQL / SQL Server / Flink SQL 完全不识别，硬写进去迁移时直接报
syntax error - 若业务真正要的是“最新订单的用户名”，
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 user_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() 当兜底方案，它只是把问题从报错阶段推迟到了数据对不上阶段。
