唯一解法是补全GROUP BY字段或用聚合函数包裹非聚合列；禁用ONLY_FULL_GROUP_BY仅掩盖问题。MySQL报错因语义模糊，需明示取值意图，窗口函数更适用于取每组最新完整记录。
直接补全 GROUP BY 字段或用聚合函数包裹非聚合列，是唯一能通过语法校验且语义自洽的解法；禁用 ONLY_FULL_GROUP_BY 只是掩盖问题，不是避免报错。
MySQL 报 “Expression #N of SELECT list is not in GROUP BY clause” 怎么办
这是 MySQL 5.7+ 默认启用 ONLY_FULL_GROUP_BY 后的强制校验，不是 SQL 写错了，而是数据库在拒绝语义模糊的查询。错误信息里的 Expression #N 指的是 SELECT 列表中第 N 个既没进 GROUP BY、也没被聚合函数包裹的字段。
- 比如
SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id中，name是Expression #2，必然报错 - 别指望 MySQL “自动选一行”，它现在不猜了——你得明说要哪一行的
name - 临时执行
SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''))能绕过，但连接池复用旧连接时可能无效；必须在同一连接内执行SELECT @@sql_mode验证是否真生效
PostgreSQL / SQL Server / Flink SQL 中 “column must appear in GROUP BY clause” 如何处理
这些系统没有 ANY_VALUE()，也不接受隐式取值，报错就是硬性拦截，没商量余地。
-
SELECT id, status, created_at FROM logs GROUP BY id在 PostgreSQL 里直接失败：因为status和created_at在每组内可能有多个值，数据库无法自主决定选哪个 - 必须显式声明意图：用
MAX(created_at)表示“最新时间”，用STRING_AGG(status, ',' ORDER BY created_at DESC)（PG）或STRING_AGG(status, ',') WITHIN GROUP (ORDER BY created_at DESC)（SQL Server）表示“按时间倒序拼接” - 如果
id是主键，整行其实可唯一确定——这时不该用GROUP BY，而该用窗口函数：ROW_NUMBER() OVER (PARTITION BY id ORDER BY created_at DESC)+ 外层WHERE rn = 1，逻辑清晰、结果确定、跨库可移植
什么时候该放弃 GROUP BY，改用窗口函数
当你需要“每组一条记录 + 原始明细字段”时，硬套 GROUP BY 是反模式。
- 想查每个用户的最新订单完整信息（
order_id,status,amount,created_at），写SELECT order_id, status, amount, created_at, COUNT(*) FROM orders GROUP BY user_id必然报错，就算关了ONLY_FULL_GROUP_BY，返回的status和created_at可能来自不同行 -
ANY_VALUE(status)不等于“最新状态”，MAX(status)是字典序最大，不是业务最新——它们都不解决“按时间取最新”这个本质需求 - 真正安全的做法是：先用窗口函数标记顺序，再过滤，例如
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders) t WHERE rn = 1
最容易被忽略的一点：字段是否“实际一致”不能靠经验判断。比如 name 看似和 user_id 一一对应，但若存在历史改名、大小写混用、前后空格或 NULL，GROUP BY user_id, name 就会把同一用户拆成多组；而 ANY_VALUE(name) 在并发扫描或索引跳读时可能每次返回不同值——这不是 bug，是它本就不承诺稳定性。
