不少开发者在升级MySQL版本后，发现原来运行正常的GROUP BY查询突然报错，错误信息通常是Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column。这个问题的根源在于MySQL 5.7及以上版本默认开启了ONLY_FULL_GROUP_BY模式，它要求SELECT中出现的所有非聚合列必须出现在GROUP BY子句中，否则直接拒绝执行。本文将详细分析报错原理，并给出几种可行的解决方案，帮助你根据实际场景选择最合适的处理方式。
一、理解报错原因与ONLY_FULL_GROUP_BY的校验原理
首先来看一个典型的报错场景。假设有一张订单表orders，包含user_name、product、amount三个字段，执行如下查询：
SELECT user_name, product, SUM(amount) FROM orders GROUP BY user_name;
在开启了ONLY_FULL_GROUP_BY模式的MySQL中，这条SQL会直接报错，因为product列既没有出现在GROUP BY子句中，也没有使用聚合函数包裹。
为什么MySQL要这样限制？这涉及SQL标准的语义问题。当按user_name分组后，一个分组内可能包含多行记录，如果SELECT中直接取product列，MySQL无法确定应该返回该分组中的哪一行的product值。在没有ONLY_FULL_GROUP_BY校验的年代，MySQL会随机返回分组中某一行的值，这个结果是不确定的，可能在数据更新后发生变化，存在严重的逻辑隐患。ONLY_FULL_GROUP_BY正是为了杜绝这种不确定性而引入的，它强制开发者为非聚合列指定明确的行为：要么加入GROUP BY，要么使用聚合函数如MAX、MIN，要么显式声明使用ANY_VALUE。
可以通过下面的语句查看当前MySQL的SQL_MODE配置：
SELECT @@GLOBAL.sql_mode; SELECT @@SESSION.sql_mode;
如果输出结果中包含ONLY_FULL_GROUP_BY字符串，说明该校验处于开启状态，这就是报错的直接原因。
二、方案一：调整SQL_MODE配置关闭校验
最直接的解决方式是移除ONLY_FULL_GROUP_BY模式。如果只是临时生效，可以在当前会话中执行：
SET SESSION sql_mode = ( SELECT REPLACE(@@sql_mode, 'ONLY_FULL_GROUP_BY', '') );
这种写法利用REPLACE函数将原配置中的ONLY_FULL_GROUP_BY字符串替换为空，避免手动重写整个模式列表导致遗漏其他配置项。SESSION级别只影响当前连接，断开后恢复原状，适合临时排查问题时使用。
如果需要全局生效，可以用GLOBAL关键字：
SET GLOBAL sql_mode = ( SELECT REPLACE(@@sql_mode, 'ONLY_FULL_GROUP_BY', '') );
但要注意，GLOBAL设置只影响修改之后建立的新连接，已有连接不受影响，而且MySQL服务重启后会失效。要想永久生效，必须修改MySQL的配置文件。Linux环境下通常是my.cnf文件，一般位于/etc/my.cnf或/etc/mysql/my.cnf，Windows环境下则是MySQL安装目录下的my.ini文件。在[mysqld]区块下添加或修改sql_mode配置：
[mysqld] sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
注意这里直接不写ONLY_FULL_GROUP_BY即可，多个模式之间用英文逗号分隔，等号两边不要有多余空格，修改完成后重启MySQL服务生效。这种方案的优点是改动一次全局有效，原有SQL无需任何修改；缺点是降低了SQL规范性校验，可能掩盖业务逻辑中的隐患，团队协作时容易被误用，建议只在接手遗留系统、短期无法改造SQL的情况下使用。
三、方案二：使用ANY_VALUE函数或改造SQL写法
从MySQL 5.7.5开始，官方提供了ANY_VALUE函数专门解决这类问题。它的作用是显式告诉MySQL：我明确知道这个列在分组内有多个值，随便取一个即可。使用方式如下：
SELECT user_name, ANY_VALUE(product), SUM(amount) FROM orders GROUP BY user_name;
ANY_VALUE的优势在于不需要修改服务器配置，只针对特定SQL生效，对系统其他部分零影响，是生产环境中比较推荐的做法。缺点是每次遇到类似查询都要手动添加，并且取到的值依然是不确定的，如果业务上对product的取值有明确要求，还是要结合具体逻辑处理。
更规范的做法是彻底改造SQL写法，让语句符合标准语义。第一种方式是把所有需要展示的非聚合列都加入GROUP BY：
SELECT user_name, product, SUM(amount) FROM orders GROUP BY user_name, product;
第二种方式是使用聚合函数明确取值规则，例如取每个用户金额最大的那条记录的商品：
SELECT o.user_name, o.product, o.amount
FROM orders o
INNER JOIN (
SELECT user_name, MAX(amount) AS max_amount
FROM orders
GROUP BY user_name
) t ON o.user_name = t.user_name AND o.amount = t.max_amount;
这种写法虽然代码量更多，但语义完全确定，查询结果稳定可靠，是长期维护项目的最佳选择。
四、各方案对比与选型建议
下面对三种主要方案做一个简单对比：
| 方案 | 生效范围 | 优点 | 缺点 |
|---|---|---|---|
| 修改SQL_MODE | 全局或会话 | 无需改动SQL，改一次全局有效 | 失去校验保护，重启需配置文件配合 |
| ANY_VALUE函数 | 单条SQL | 影响面小，不需要改配置 | 取值不确定，每条SQL都要改 |
| 改造SQL写法 | 单条SQL | 语义明确，结果稳定 | 改造成本高，SQL可能变复杂 |
实际选型时建议遵循这样的原则：如果是从旧版本迁移过来的遗留系统，SQL数量庞大且短期无法逐一验证，可以先在配置文件中关闭ONLY_FULL_GROUP_BY保证业务正常运行，同时制定长期改造计划；如果是新项目或少量SQL报错，优先选择ANY_VALUE或改造SQL写法，保持数据库的严格校验，从源头杜绝不确定的查询结果。
总结来说，GROUP BY报错本质上是MySQL对SQL标准语义的强制校验，而非系统故障。遇到报错时不要急于关闭校验，先分析业务上真正需要什么样的分组结果，再选择对应的解决方案，这样才能既解决问题，又保证数据的正确性和系统的可维护性。
GROUP BY报错SQL_MODEONLY_FULL_GROUP_BY修改时间：2026-09-02 02:54:29