这是MySQL 5.7+和PostgreSQL/SQL Server等严格模式下的标准语义拦截信号，表明SELECT中存在既未聚合也未出现在GROUP BY中的字段，数据库因无法确定返回哪一行的值而拒绝执行。
ERROR 1055 “Expression not in GROUP BY clause” 是什么信号
这是 MySQL 5.7+ 和 PostgreSQL / SQL Server 等严格模式下的标准拦截，不是语法错误，而是语义拒绝：数据库明确告诉你——SELECT 列表里的某个字段既没进 GROUP BY，也没被聚合函数包裹，它无法确定该返回哪一行的值。
典型报错：ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause，意思是第 2 个 SELECT 字段（比如 name）在分组后存在多值可能，数据库拒绝“猜”你想要哪一个。
- 不是字段写错了，是 SQL 标准强制要求结果确定性
- 哪怕
name实际上和user_id是 1:1 关系，数据库也不会自动推断——必须显式声明 - PostgreSQL / SQL Server 根本不提供
ANY_VALUE()这类绕过机制，直接报错，不执行
为什么加进 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 - 别名只在
SELECT和HAVING中可用，WHERE和ORDER BY（无子查询时）都不认
ANY_VALUE() 真的能解决问题吗
它只是告诉 MySQL “我接受不确定性”，但代价是结果不稳定、不可迁移、且与业务意图常不匹配。
-
ANY_VALUE(name)在同一查询中多次执行，可能返回不同值——取决于优化器是否启用并行扫描、索引是否覆盖、甚至 InnoDB 的页读取顺序 - 仅存在于 MySQL 5.7.5+，PostgreSQL / SQL Server / Flink SQL 完全不识别，硬写进去迁移时直接报错
- 如果业务真正要的是“最新订单的用户名”，而你用了
ANY_VALUE(name)，那跟“最新”毫无关系；换成MAX(name)更糟——那是字典序最大，不是时间最新 - 云数据库（如阿里云 RDS）通常禁用
SET GLOBAL，你没法靠它临时绕过，只能重写 SQL
最容易被忽略的一点：即使你成功让 SQL 跑通了，只要没搞清字段和分组键之间的逻辑关系（是一对一？一对多？还是根本无对应），结果就只是“看起来不报错”，而不是“正确”。
