MySQL only_full_group_by报错详解：从原理到落地排坑指南

MySQL报错only_full_group_by：从原理到落地的完整排坑指南

这个报错应该是MySQL里除了1064语法错误之外，最容易让开发者血压升高的一条了。你高高兴兴写了一条分组查询，本地跑得挺好，一到测试环境或者同事电脑上就报this is incompatible with sql_mode=only_full_group_by，而且那台机器上的MySQL还是5.7以上版本。更气人的是，网上搜到的方案五花八门，有让你改配置的，有让你改SQL的，还有让你降级MySQL的，到底哪个靠谱？这篇文章我按自己的实操经验，把这条报错的前因后果、几种解决路径、以及每一条路径的适用场景和坑一次说清楚。不管你是刚入行的新人，还是被这个问题折磨过的老兵，照着这篇文章的思路去排查，基本十分钟内能把问题定位并解决。

先说结论：这条报错的本质不是MySQL坏了，也不是你的SQL语法写错了，而是服务端开启了only_full_group_by这种SQL模式后，对GROUP BY的语义做了严格的合规性检查。MySQL 5.7.5 开始这个模式默认开启，导致大量老项目升级或者换环境时突然冒出这个错误。解决方案没有唯一的“完美”，只有“适合你当前场景”的方案：能改配置就去改配置，不能改配置就改SQL，都被限制死了就上兼容层。

1. 报错原理：这条错误到底在抱怨什么

1.1 从一段触发报错的SQL说起

先看一个最典型的触发场景。假设有一张订单表：

SELECT user_id, MAX(amount) AS max_amount, order_date FROM orders GROUP BY user_id;

在MySQL 5.7及以上版本，如果启用了only_full_group_by，这条SQL立刻报错，报错信息里还会带上完整的sql_mode值，大概长这样：

ERROR 1055 (42000): Expression #3 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'test.orders.order_date' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

读懂这条报错的关键在括号里的那句话：SELECT列表的第三项（order_date）不在GROUP BY子句里，且没有对order_date使用聚合函数。换句话说，MySQL在问你：你把订单按用户分组了，但你那order_date到底是取组里哪一条订单的日期？是第一条的？还是最后一条的？你不说清楚，MySQL就不干活。

1.2 为什么MySQL要搞这么一出

很多人觉得这个限制很烦，但站在数据库引擎的角度，这个限制是有道理的。SQL标准里，GROUP BY分组之后，每一组可能包含多行数据。如果你在SELECT里直接写了某个普通列，数据库不知道你想让这个列显示哪一行的值——这种“不确定查询”在标准SQL里本身就属于语义模糊。MySQL 5.7 之前的版本不检查这个，查出来哪一行是哪一行，完全由执行计划决定，这就是经典的“碰运气”。同一套代码，在A环境数据量小时跑出来的是第一行的值，到B环境数据量大时跑出来的可能是另一行的值。哪天这个隐藏的bug爆出来，排查成本远远高于改一条SQL的成本。

only_full_group_by这个模式的作用，就是把这种“模糊查询”直接拦截在语法检查阶段。它不是MySQL在刁难你，而是MySQL在帮你把潜在的数据错误风险提前暴露出来。理解了这一层逻辑，你就明白了：最正确的解决思路不是关掉这个模式，而是让你的SQL明确表达意图。

1.3 sql_mode是什么，它管着哪些事

sql_mode是MySQL一个非常核心的配置项，它是一个由多个模式名用逗号拼接的字符串。每个模式名对应一种行为开关，例如：

说句题外话，很多人在排查其他怪问题时也会撞见sql_mode的影子。比如插入数据报错说日期不合法、除数为0报错，甚至存储引擎被悄悄替换，都和这一长串模式有关。ONLY_FULL_GROUP_BY只是这条链路上最出名的那个。理解sql_mode的整体结构，对后面排查问题有好处，因为你会发现不同机器上默认模式可能不一样，这就是“本地正常、线上报错”的一个常见根源。

2. 方案选型：五条路，条条都能走到罗马

解决这个报错，我在实际项目里用过的、见过别人用过的方案大概能分成五类。每一类都有明确的适用场景，我给它们排个序，你按顺序选即可。

2.1 简单粗暴型：去掉严格模式

这个方法网上最多，核心思路就一句话：把ONLY_FULL_GROUP_BY从sql_mode里拿掉。执行方式分临时和永久两种。

临时方式在当前会话直接生效，断开连接就失效：

SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

需要先查一下当前模式的完整值，再手动摘掉ONLY_FULL_GROUP_BY。别把其他模式弄丢了，否则可能导致其他行为发生变化。

永久方式需要改配置文件（Linux下是/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf，Windows下是my.ini），在[mysqld]段下加一行：

[mysqld] sql_mode = STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

然后重启MySQL服务生效。

这个方案我只建议在以下场景用：这是一个内部系统、旧系统，SQL没法大规模改了，而且你确定所有分组查询返回的“非分组列”不管取哪行都不会造成数据错误（比如那些列在各行里值都一样）。如果你的系统是给外部用户用的，或者涉及财务、订单这类一毛钱都不能错的数据，直接关掉严格模式就是在给自己埋雷。

2.2 曲线救国型：用ANY_VALUE()塞住检查

这个方案特别有意思，它不关模式，而是用MySQL提供的ANY_VALUE()函数来告诉优化器：“别管了，这一列我随便取一行就行。”改造后的SQL长这样：

SELECT user_id, MAX(amount) AS max_amount, ANY_VALUE(order_date) FROM orders GROUP BY user_id;

加上ANY_VALUE()后，查询能正常执行。这个函数的作用就是明确表示“我知道这列有多个值，我不在乎具体取哪个”。

实际用下来，这个方案有两个明显优势：一是它不需要改服务端配置，不影响其他查询的行为；二是它比关掉整个严格模式要安全得多，因为只有显式加了ANY_VALUE()的列才被放开。我在一些没法动配置的托管数据库（比如云厂商的RDS实例）上，基本都是靠这一招解决问题的。需要注意的是，MySQL 5.7及以上版本才有ANY_VALUE()，如果你还在用老版本就享受不到这个便利了。

2.3 拨乱反正型：改写SQL，按规范来

从数据库规范的角度，最正确的做法永远是把SQL改成完全符合标准语义的写法。就我们开头那条SQL来说，如果业务上想取的是“每个用户最大金额那笔订单的下单日期”，可以这么改：

SELECT user_id, amount AS max_amount, order_date FROM orders o INNER JOIN ( SELECT user_id, MAX(amount) AS max_amount FROM orders GROUP BY user_id ) t ON o.user_id = t.user_id AND o.amount = t.max_amount;

这样SELECT出来的每一列要么在GROUP BY里，要么经过了聚合，要么来自连接后的明确匹配行，完全合法。如果业务上想取的是“每个用户最近一笔订单日期”，那思路类似，用MAX(order_date)关联或者窗口函数都行。

如果用的MySQL 8.0，还能用窗口函数把这种需求写得更优雅：

SELECT user_id, amount AS max_amount, order_date FROM ( SELECT user_id, amount, order_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rn FROM orders ) t WHERE rn = 1;

窗口函数的执行效率在这个场景下通常也不会差。这条路的缺点也很明显：如果报错源头是几十条散落在代码里的查询，工作量大不说，改完还得回归测试。

2.4 一次性生效型：全局修改但不停服（动态变量）

前面说改配置文件要重启，有些生产环境数据库是不能随便重启的。MySQL提供了一个好消息：sql_mode是动态变量，不需要重启也能永久生效，只要用它配套的SET GLOBAL命令就行：

SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

执行后，新建立的连接都会用这个值。已经存在的连接（包括你自己当前这个）不会立即生效，所以你要自己再执行一次SET SESSION才能看到效果。

这个方案有一个大坑必须提：SET GLOBAL修改的是运行时变量，它不会写进配置文件，MySQL服务一旦重启，配置又变回去了。如果你要用这个方案“救火”，务必在之后把配置文件也同步改掉，否则下次重启报错卷土重来，你还得排查半天为什么之前改了没用。

2.5 治本之策型：规范开发规范 + 代码审查管控

这个方案不是一次性的技术操作，而是团队层面的流程改良。既然我们理解了这条报错的本质是“SQL语义模糊”，那么在团队协作中，最治本的办法是让这类SQL永远不进入主分支。

具体做法包括：数据库规范的文档里明确写出“GROUP BY查询中SELECT列必须是分组列或聚合列”；代码评审清单里加上一条“运行SQL是否符合分组语义规范”；有条件的话，在测试环境的MySQL上也开启only_full_group_by，让问题在开发阶段就暴露出来。

这条方案单独看解决不了你眼前的报错，但它能让你以后再也不会被这个问题困扰。我见过很多团队，报错一次改一次，改了半年还在改，就是因为没人把这个规则固化下来形成约束。

3. 实操记录：从定位到修复的完整过程

这一章我以一次真实的运维排障经历为蓝本，按步骤记录整个过程。场景是一个业务系统从MySQL 5.6升级到5.7后，后台报表模块大面积报这个错。

3.1 第一步：确认当前sql_mode的值

登录MySQL命令行，执行：

SELECT @@GLOBAL.sql_mode; SELECT @@SESSION.sql_mode;

当时输出的值：

STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

看到这个值，我心里大概有数了：这台实例的5.7默认配置里确实带着ONLY_FULL_GROUP_BY。注意看输出里还有STRICT_TRANS_TABLES，这说明严格模式是开着的，插入非法数据也会报错——这个模式建议保留，因为它能防止脏数据写入，和我们要解决的问题没有冲突。

3.2 第二步：定位报错SQL的分布

这一步很有必要。如果只是测试环境报错，可以直接粗暴改配置；但生产环境我建议先搞清楚有多少地方受影响。做法是把应用日志里带有ERROR 1055的SQL全部捞出来，排除掉重复后归个类。

当时我们捞出的报错SQL大体分两类：

• 第一类是报表统计场景，SELECT里带非分组列但心里其实想取分组内的任意一条，比如取部门名称、取产品名称，这些列在分组内是等值的。
• 第二类是取“每组中某个极值对应的整行数据”，比如“每个订单金额最大的那条记录的备注”。

第一类我用ANY_VALUE()改造最划算，第二类则用了子查询关联或窗口函数改写。

3.3 第三步：制定修复策略

考虑到当时生产库不能随便重启，我采取了组合策略：

策略A：对所有属于“等值列”的查询，用ANY_VALUE()包一下非分组列。这类查询的SQL语义本身就是“组内各行该列值相同”，用ANY_VALUE()完全不影响结果，只是消除了语法层面的歧义。

具体操作像这样，在Java的Mapper XML里找到对应SQL：

<select id="selectMaxAmountByUser" resultType="map"> SELECT user_id, MAX(amount) AS max_amount, ANY_VALUE(order_date) AS order_date FROM orders GROUP BY user_id </select>

策略B：对所有属于“取极值整行”的查询，先用子查询算出分组内的极值再内连接回原表。这一步要仔细验证业务逻辑，不是机械地套格式，否则容易把原本的结果集语义改错了。

3.4 第四步：验证与灰度上线

改完后，先在测试库跑一遍全量报表用例。这里有一个细节：测试的时候不能只看“不报错就完成任务”，还要看改造前后同一份数据查出来的结果集是否一致。我习惯把改造前的SQL（在5.6环境上跑）和改造后的SQL（在5.7环境上跑）各导一份结果，用diff工具比对。确保数据一致后，再上线到生产环境观察。

当时还顺手处理了一个衍生的糟心事：平台上有个定时任务脚本是在MySQL 5.6时代写的，用了SELECT ... GROUP BY但没加聚合，当时查出来的数据刚好是需要的那个值。升级到5.7后直接报错，经排查是5.6版本的执行计划碰巧把“分组内第一行”作为结果返回了，功能上碰巧正确但完全不可控。这种历史债务只能靠改写SQL正向解决，没什么捷径。

3.5 第五步：处理MySQL 8.0的额外差异点

如果你的环境直接上到了MySQL 8.0，那要再多留个心眼：8.0里NO_AUTO_CREATE_USER这个模式被移除了（5.7里用它控制不能用GRANT自动建用户），而且默认的字符集排序规则变成了utf8mb4_0900_ai_ci。如果你是从5.7平滑迁移，改sql_mode配置时注意别把一个已经失效的模式名写进去，否则MySQL启动的时候会报错。最佳实践是先看SELECT @@GLOBAL.sql_mode;的实际输出，以那个为底本删减，而不是凭记忆拼一长串。

4. 排坑实录：改了还是不生效？排查思路来了

这一章专门整理我在帮人排查这个报错时遇到的高频问题。这些坑网络文档很少系统性提过，我集中写出来供你对照。

4.1 改了my.cnf但重启后没生效

这个坑十个人里有八个踩过。排查步骤依次是：

第一，确认你改的是不是MySQL真正读取的配置文件。MySQL读取配置文件的顺序和平台有关，Linux上经常有多个my.cnf存在，用mysql --help | grep 'Default options'可以列出搜索路径。我看到过有人改了/etc/mysql/my.cnf，但实际生效的是/etc/my.cnf，两处配置一叠加，后者把前者的值覆盖了。

第二，确认sql_mode是不是只在某个section下配置了。注意，sql_mode必须放在[mysqld]段，不是[mysql]段也不是[client]段。放错段位就相当于没配置。

第三，确认配置文件里有其他sql_mode重复行。有些自动化运维脚本会自动生成配置，可能追加了多行sql_mode，MySQL会采用最后读到的一行，和你想的不一样。

经验做法：改完配置后，先执行mysql -e "SELECT @@GLOBAL.sql_mode;"查看运行时值，而不是急着重启。如果运行时值已经变了，就不用重启；如果没变，再查配置文件的问题。

4.2 用Navicat等客户端连接时版本模式不同

Navicat这类图形客户端本身不会修改sql_mode，但不同连接方式可能会让你产生“客户端改了没用”的错觉。具体来说，SET SESSION只对当前会话生效，Navicat的查询窗口每次打开都可能复用或新建连接，行为不完全可控。所以你在Navicat里执行了SET SESSION后，新开一个查询窗口测试，发现又报错，这其实是正常的——那是一个新的会话，会话变量重置了。

建议是在Navicat里排查问题时，先用一条命令测试：

SELECT @@SESSION.sql_mode;

确认当前会话的模式确实包含ONLY_FULL_GROUP_BY再动手。如果排查遇到“一会儿报错一会儿不报错”，优先怀疑是不是连接池在中间捣乱——Java应用连接池里的连接是复用的，某个连接执行过SET SESSION就会一直有效，而另一个新连接没执行过就会报错。这种“间歇性报错”最迷惑人。

4.3 自建MySQL和云数据库（RDS）的处理差异

如果你用的是云厂商的RDS，情况会有点特殊。RDS控制台通常提供了“参数组”功能，你可以直接在控制台里修改sql_mode参数，然后提交修改。提交后，大多数云数据库需要重启实例才生效，少数可以动态生效。具体以你自己的控制台页面提示为准。

特别提一点：有些云数据库的默认参数里，除了ONLY_FULL_GROUP_BY之外还有一个叫PAD_CHAR_TO_FULL_LENGTH的坑模式，这会让CHAR类型的比较忽略尾部空格。如果你在RDS上改参数，建议先查一下云厂商提供的默认参数文档，别只挑一个模式改，容易引发其他兼容问题。

4.4 项目用了ORM框架（MyBatis、JPA等）怎么定位SQL

很多小伙伴说“我代码里没直接写SQL，这个报错是哪来的？”这里有个技巧：MySQL的general_log可以记录所有执行的SQL语句。在排查期可以临时开启：

SET GLOBAL general_log = 'ON'; SET GLOBAL log_output = 'TABLE';

然后从mysql.general_log表里去捞报错时间段前后的SQL记录，按command_type='Query'过滤，很快就能找出是哪条SQL触发的。排查完记得关掉：

SET GLOBAL general_log = 'OFF';

这个方法还能用来抓ORM框架自动生成的SQL，非常实用。不过注意生产环境开启general_log会有性能损耗和磁盘占用风险，只建议在低峰期短时间开启。

4.5 有一条SQL报错，但同样的SQL在5.6不报错

这是历史版本差异问题。MySQL 5.6及之前版本默认不开启ONLY_FULL_GROUP_BY，不检查也不报错，能跑。但不是因为它合法，只是因为它“没被检查”。这就像一个人无证驾驶了很久没被查，不代表他有驾驶证。所以升级版本后报错不是MySQL变得“不兼容”，而是它开始严格执法了。

如果你的业务确实依赖了这种“碰运气”查询的结果，比如取分组内第一行的某个字段值，那升级前就必须改掉。不要试图通过改配置蒙混过关，因为你不知道哪一天优化器改了执行路径，同样的SQL就返回另一行的值了，那才是真正的数据事故。

5. 避坑经验与长期策略

5.1 不要为了消错而关闭严格模式

把sql_mode里的ONLY_FULL_GROUP_BY拿掉很简单，但如果你的MySQL版本同时开启了STRICT_TRANS_TABLES，我强烈建议保留后者。严格模式是MySQL保证数据完整性的重要防线，它能在插入超长字符串或者非法的空值时直接报错，而不是静默地截断或替换，这可以避免大量脏数据悄悄落库。

如果你真的决定关掉ONLY_FULL_GROUP_BY，至少应该做到以下两点：一是形成书面记录，说明为什么关、什么时候关的、谁决定的；二是在代码评审时特别注意新增的分组查询，自己多审一道，防止“不检查=随便写”的风气蔓延。

5.2 关于“完美解决方案”的答案

这篇博文的标题叫“完美解决方案”，但凡是干过几年数据库的人都知道，不存在一个放之四海而皆准的完美方案。所谓的完美，是在理解原理的基础上，针对你的现状找到风险最低、成本最合适的路径。如果让我给一个通用决策模型，大概是这样的：

• 系统无法大面积改SQL，且非生产环境 → 改配置去掉ONLY_FULL_GROUP_BY，快速恢复业务。
• 系统无法大面积改SQL，但是生产环境且不能随意重启 → 用SET GLOBAL临时生效，同时改造SQL，错峰重启后再固化到配置文件。
• 系统能改SQL，且报错总数不多 → 用ANY_VALUE()或重写子查询，保持严格模式打开。
• 系统在云数据库上，无法改配置 → 只能走改写SQL这条路，别无选择。
• 团队协作开发，反复出现该报错 → 开启开发环境严格模式，把规范前移，从源头拦截。

5.3 有没有一劳永逸的办法

如果业务上确实经常遇到“取分组内某条记录的属性”这类需求，MySQL 8.0的窗口函数会是更现代的解法。窗口函数（ROW_NUMBER()、RANK()、FIRST_VALUE()、LAG()等）可以精确表达“每组第N行”“每组最大值的整行”这类语义，语义清晰且经过了优化器校验。这比靠子查询关联的可读性和维护性都强很多。

长远来看，团队里应该沉淀一份《SQL开发规范》，把这条规则写进规范：“SELECT列表中的列，要么是分组列，要么被聚合函数包裹，要么使用了ANY_VALUE()且确认组内等值。”同时，把测试环境的MySQL版本与生产保持大版本一致（如都是MySQL 8.0），避免“本地5.7不报错，线上8.0报错”这类环境差异问题。

6. 结语与一点个人体会

我在实际处理中体会最深的一点是：一条数据库报错，往往不是改一行配置或者改一条SQL那么简单，它背后是你对数据库语义的理解深度。only_full_group_by这条报错的每一行错误信息都写得清清楚楚，指明了是SELECT列表的第几项出了问题、问题是什么。如果你看一眼报错就急着百度复制粘贴配置，那你永远只会修这一条报错；如果你把报错信息当成数据库在和你对话，你会慢慢学会怎么写出语义明确的SQL。

最后再分享一个小技巧：不管最后用了哪个方案，修复完了一定要把“修复记录”写进项目的数据库变更文档里，内容包括报错信息、涉及的SQL、当时的sql_mode值、修复方案和验证结果。这套记录看起来不起眼，但下次有人再踩同一个坑的时候，他能顺着记录在十分钟之内解决，而不是重新查半天资料。这也算是我被这个错误折腾过几次之后养成的习惯，希望对你有用。