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 先算出列，再在外层筛选。
