数据库拒绝执行是因为sql标准强制语义确定性：select中未聚合且未出现在group by中的字段会导致结果不确定，如“一组5条name该返回哪条”；报错信息“not in group by clause”明确指出第n个字段既未分组也未聚合，mysql 5.7+、postgresql、sql server均严格拦截，any_value()仅mysql特有且牺牲稳定性，根本解法是厘清函数依赖或改用窗口函数。
SELECT里有字段没进GROUP BY也没聚合，数据库直接拦你
这不是字段“无效”，是SQL标准在强制语义确定性——数据库无法回答“这一组里有5条name，该返回哪一条？”。报错信息里带 not in GROUP BY clause 就是明确告诉你：第N个SELECT字段既没出现在 GROUP BY 子句中，也没被 MAX()、COUNT() 这类聚合函数包裹。
常见错误写法：SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id → name 没聚合也没分组，MySQL 5.7+、PostgreSQL、SQL Server 全部拒绝执行。
- MySQL 5.7+ 默认开启
sql_mode=ONLY_FULL_GROUP_BY，严格遵循 SQL92 标准 - PostgreSQL / Oracle / SQL Server 从不妥协，没有
ANY_VALUE()这种绕过机制 - 哪怕字段在业务上“实际唯一”（比如
user_id和name是1:1），SQL引擎也不会自动推断函数依赖
加进GROUP BY也不一定对，分组逻辑可能已失真
表面补全字段能过语法检查，但结果可能完全偏离业务意图。分组键选错，统计就废了。
-
GROUP BY user_id, name：若name有大小写混用、前后空格或历史改名，同一user_id会被拆成多组，总数虚高 -
GROUP BY created_at（毫秒级时间戳）：几乎每行都不同，等价于没分组，COUNT(*)变成行计数 -
GROUP BY CAST(user_id AS CHAR)vsGROUP BY user_id：类型不一致时，MySQL 可能视为不同分组键，结果不一致 -
NULL值全部归为一组，但业务上可能希望每个NULL算独立个体（比如未填手机号的用户要单独计数）
ORDER BY里用别名失败，不是写错了，是执行顺序卡死的
SQL 执行顺序固定为：GROUP BY → 聚合 → SELECT → ORDER BY。所以 SELECT dept_id, AVG(salary) AS avg_salary FROM t GROUP BY dept_id ORDER BY avg_salary DESC 中，avg_salary 在 ORDER BY 阶段还没“出生”。
- 最稳写法：
ORDER BY AVG(salary) DESC - 外层包装可行：
SELECT * FROM (SELECT dept_id, AVG(salary) AS avg_salary FROM t GROUP BY dept_id) t ORDER BY avg_salary DESC - 别名在
HAVING或WHERE里也一样不可用，原因相同
ANY_VALUE()只是掩耳盗铃，迁移和稳定性全崩
ANY_VALUE(name) 不是解决方案，是放弃确定性的信号灯。它只存在于 MySQL 5.7.5+，其他数据库根本不认。
- 返回值不保证可重复：取决于索引覆盖、并行扫描开关、甚至 InnoDB 页读取顺序
- 云数据库（如阿里云 RDS）通常禁用
SET GLOBAL，你连临时关ONLY_FULL_GROUP_BY都做不到 - 如果业务要的是“最新订单的用户名”，
ANY_VALUE(name)和“最新”毫无关系；MAX(name)是字典序最大，也不是时间最新 - 真正需要明细字段 + 分组聚合时（比如查每个用户的最新订单 + 用户姓名），该用窗口函数或子查询，而不是硬套
GROUP BY
最容易被忽略的点：只要没搞清字段和分组键之间是否存在函数依赖（比如主键 → 全行），就别指望靠加字段或换聚合函数蒙混过关。SQL 不会替你猜业务逻辑。
