GROUP BY执行早于SELECT，原始行已不可见，故非分组非聚合字段在SELECT中会报错；这是SQL标准语义限制，非语法错误，需用GROUP BY字段、聚合函数或窗口函数解决。

GROUP BY 执行早于 SELECT，原始行已不可见

报错不是语法问题，而是 SQL 执行顺序决定的语义限制。标准执行流程是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，GROUP BY 阶段就把多行压缩成一组，进入 SELECT 时，原始各行的字段值（比如 name、status）已经不可访问——数据库只能返回分组键本身或聚合结果（如 COUNT(*)、MAX(created_at)）。如果你在 SELECT 里写了个没聚合也没分组的 name，它根本不知道该从哪一行取。

MySQL 报 “Expression #x of SELECT list is not in GROUP BY clause” 怎么定位

这不是 bug，是 ONLY_FULL_GROUP_BY 模式在拦截语义不确定的查询。确认方式很直接：

• 运行 SELECT @@sql_mode;，看输出是否含 ONLY_FULL_GROUP_BY
• 查版本：SELECT VERSION();，MySQL 5.7.5+ 默认开启，8.0+ 更严格（连主键隐式依赖都不认）
• 逐个检查 SELECT 列表：每个字段要么在 GROUP BY 中完整出现，要么被聚合函数包裹（如 ANY_VALUE(name)、MAX(status)），要么是 GROUP BY 字段的确定性派生（如主键列上 SELECT id, name FROM t GROUP BY id 在 PostgreSQL/KingbaseES 中仍报错，因不推导函数依赖）

加进 GROUP BY 就安全？小心语义漂移和性能陷阱

补字段能过编译，但可能让结果变错或变慢：

• GROUP BY user_id, name：如果 name 有大小写混用、前后空格或历史改名，同一用户会被拆成多组，统计数虚高
• GROUP BY created_at（毫秒级时间戳）：几乎每行都不同，等效于没分组，COUNT(*) 变成行数
• GROUP BY DATE(created_at)：跨时区场景下，UTC 时间 2026-10-02 00:10 转成本地日期可能变成 2026-10-01，导致数据切错组
• NULL 值统一归为一组，但业务上可能代表“未填写”“未知”“已删除”，强行分组会掩盖数据质量问题

真正该用窗口函数替代 GROUP BY 的场景

当你需要“每组一条记录 + 完整原始字段”（比如最新订单的 order_id、status、amount），硬套 GROUP BY 是反模式：

• 错误写法：SELECT order_id, status, amount FROM orders GROUP BY user_id → 必报错，且就算关掉 ONLY_FULL_GROUP_BY，status 和 amount 可能来自不同行
• 正确做法：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，更紧凑
• 窗口函数不压缩行，所有原始字段都可用，PARTITION BY 只定义计算范围，不影响行结构

最容易被忽略的一点：窗口函数结果不能在 WHERE 中直接过滤，因为它在执行顺序中晚于 WHERE；必须用子查询或 CTE 先算出列，再在外层筛选。