数据库严格执行SQL标准的GROUP BY语义：SELECT中非聚合列必须出现在GROUP BY或聚合函数中，否则报错以避免不确定结果；ANY_VALUE()仅是免责声明，窗口函数才是获取组内明细的正确方案。
这不是数据库“变严格”了，是它终于按 SQL 标准执行语义校验——SELECT 中每个非聚合列，必须明确出现在 GROUP BY 子句里，或被包裹进聚合函数（如 MAX()、ANY_VALUE()），否则数据库无法确定该取哪一行的值。
报错本质是语义拒绝，不是语法错误
数据库执行 GROUP BY 时，先把数据按分组键拆成若干组，再把每组“压成一行”。这时如果 SELECT 里写了没聚合也没分组的字段（比如 name），而组内 name 实际有张三、李四、王五三个值，数据库不会猜、不随机选、也不按插入顺序取——它直接报错，避免返回不可信结果。
-
Expression #2 of SELECT list is not in GROUP BY clause（MySQL）或column "name" must appear in the GROUP BY clause（PostgreSQL）都是同一语义拦截 - 哪怕你关掉 MySQL 的
ONLY_FULL_GROUP_BY，返回的name仍是不确定的：可能来自任意匹配行，且优化器重写、并发扫描、甚至页读取顺序变化都可能导致结果不同 - PostgreSQL / SQL Server / Oracle 从不妥协——它们压根不提供
ANY_VALUE()这类“敷衍接口”，报错就是硬性拒绝
为什么补全 GROUP BY 字段还可能出错
看起来加进去就完事，但实际容易踩语义陷阱：
- 时间字段如
created_at（含毫秒）直接进GROUP BY，几乎等于没分组——每条记录时间都不同，COUNT(*)就变成行计数 - 字符串字段含
NULL时，所有NULL被归为一组，但业务上“未填写”和“明确为空”可能需区分处理 -
name和user_id看似 1:1，但若存在历史改名、大小写混用、前后空格，GROUP BY user_id, name会让同一user_id拆成多组，统计数虚高 - 跨时区场景下
DATE(created_at)分组可能切错日期：UTC 时间2026-06-05 00:10在东八区是 6 月 5 日上午 8:10，但按本地DATE()切就变成 6 月 4 日
ANY_VALUE() 不是解药，是免责声明
ANY_VALUE(name) 的真实含义是：“我接受不确定性”，不是“帮我挑一个合理的”。
- 它只存在于 MySQL 5.7.5+，PostgreSQL / SQL Server / Flink SQL 完全不识别，硬写进去迁移时直接报错
- 同一查询多次执行，可能返回不同
name——取决于是否启用并行扫描、索引是否覆盖、甚至 InnoDB 的页读取顺序 - 如果业务真正要的是“最新订单的用户名”，而你用了
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有重复，逻辑清晰、结果确定、跨库可移植
最常被忽略的一点：真要业务可靠，就别绕开规则。用 ANY_VALUE() 或临时关模式，只是把问题藏得更深而已——它掩盖了“你其实没想清楚这个字段在组内到底该代表什么”的事实。
