做数据分析或日常开发时，如果你遇到过这么个神仙报错——“Expression #1 of SELECT list is not in GROUP BY clause”，八成会一头雾水。别慌，这其实不是你的SQL写错了，而是MySQL从5.7版本开始，默认开启了ONLY_FULL_GROUP_BY模式，相当于数据库在说：“你这个查询语义没定义清楚，我拒绝执行。”比如我经常举的例子：SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id里，name这个字段既没被纳入分组条件，也没用聚合函数包裹——你说数据库该取哪一行的name？
MySQL报错“Expression #1 of SELECT list is not in GROUP BY clause”怎么办
最稳妥的方案是补全分组字段，把name加入GROUP BY user_id, name。如果业务逻辑上确认user_id → name是函数依赖关系，比如user_id是外键且关联名称表，那可以用ANY_VALUE(name)来显式告诉数据库“这事我负责”。但必须警惕的是，ANY_VALUE()并不保证结果稳定性——换执行计划或数据库升级后，它返回的值可能说变就变。
不推荐临时修改sql_mode。有人会在会话级跑一句SET SESSION sql_mode = REPLACE(@@sql_mode, 'ONLY_FULL_GROUP_BY', '')，虽然速度快，但风险不小——REPLACE是按字符串匹配处理的，万一ONLY_FULL_GROUP_BY前后逗号多一个少一个，可能误删别的模式，比如把STRICT_TRANS_TABLES里的TABLES干掉了。更关键的是，永久改配置相当于把报警器给关了，SQL逻辑本身的问题还在那里，迟早要还。
PostgreSQL/SQL Server报“column must appear in GROUP BY clause”怎么处理
PostgreSQL和SQL Server比MySQL更严格，它们没有ANY_VALUE()这个逃逸通道，也不允许隐式取值。所以SELECT id, status, created_at FROM logs GROUP BY id必然触礁——status和created_at在同一分组内可能存在多条记录，数据库不可能替你拍板选哪一条。
这时候必须把意图明明白白写在代码里：
- 用聚合函数明确语义——比如
MAX(created_at)取最新时间，STRING_AGG(status, ',')（PostgreSQL）或加排序的STRING_AGG(status, ',' ORDER BY created_at DESC)把状态合并并排序。 - 如果
id是主键，整行记录天然可唯一确定，那就别用GROUP BY了，改用窗口函数更合适：ROW_NUMBER() OVER (PARTITION BY id ORDER BY created_at DESC) = 1来筛选每组最新的那条记录。 - 尽量避免“先GROUP再JOIN回原表”的绕路写法。这种方案一旦遇到NULL值、重复键或者JOIN条件设得不够严谨，数据漏得你欲哭无泪，维护成本也高得离谱。
Flink SQL报“is not being grouped”错误修复要点
Flink SQL严格遵循SQL标准，SELECT a, b, c FROM t GROUP BY a, b中c不分组也不聚合，就会触发同样的报错。把c直接加进GROUP BY虽然看起来很简单，但坑的是：如果c本身是高基数字段，比如UUID或毫秒级时间戳，分组数会瞬间膨胀，任务不是OOM就是超时。
比较靠谱的做法是用聚合替代：
- 取最新值可以用
LAST_VALUE(c) OVER (PARTITION BY a, b ORDER BY ts DESC)，注意配合ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING限定窗口范围。 - 如果业务只需要任意一行数据，Flink 1.16以上可以用
COLLECT_LIST(c)[0]，或者用ARRAY_AGG(c)[1]取首个元素。 - 还有一个常被忽略的点：
c这个字段在查询中是否真的有必要存在？有些时候，前端分页或展示逻辑混进了聚合层，这属于职责错位，应该拆到应用层去处理。
Azure Databricks报“[GROUP_BY_AGGREGATE] Aggregate functions are not allowed in GROUP BY”
这个报错信息很直白——别把聚合函数往GROUP BY里塞。像GROUP BY a, SUM(b)这种写法本来就是非法的，GROUP BY只负责定义分组维度，聚合计算应当在SELECT或HA VING里进行。
常见的修正策略：
- 想聚合就把表达式挪到
SELECT：从GROUP BY a, SUM(b)改成SELECT a, SUM(b) FROM ... GROUP BY a。 - 想筛选聚合之后的结果，就挪到
HA VING：比如HA VING SUM(b) > 100。 - 特别注意检查是否误用了窗口函数的别名——Databricks对
OVER()别名在GROUP BY中的引用相当敏感，直接写原始表达式反而更安全。
说到底，真正的麻烦从来不是语法报错本身，而是你写下一行ANY_VALUE()或MAX()之后，连自己都忘了这个字段原本应该代表什么含义。线上报表跑得慢、数据对不上、同事问“这一行的name到底是谁的”，问题往往就卡在这一环。把意图写清楚，比消灭报错重要得多。
