MySQL ERROR 1055深度解析：ONLY_FULL_GROUP_BY报错原因与五种解决方案

干后端这几年，MySQL 报错里跟开发者打交道最频繁的，我觉得 1055 得排前三。尤其是项目从 5.6 升到 5.7 之后，原来跑得好好的统计查询突然一夜之间全炸了，控制台刷出一串ERROR 1055 (42000)，后面还挂着一长串Expression #2 of SELECT list is not in GROUP BY clause。第一次见到的人基本都会懵：我 SQL 一个字没改，怎么突然就不让跑了？

其实这个报错就是 MySQL 的ONLY_FULL_GROUP_BY模式在起作用。它不是什么洪水猛兽，而是 MySQL 5.7 之后默认开启的一种 SQL 规范性检查，专门盯着用了GROUP BY的查询，防止你查出"不明确"的数据。说难听点就是 MySQL 在帮你避坑，只不过它选了最不近人情的方式告诉你。这篇文章我就把这个报错掰开揉碎讲清楚，包括底层逻辑、五种解决方案、以及我在真实项目里踩过的各种坑。不管你是刚学 SQL 的新手，还是被线上报错搞得焦头烂额的在职开发，这篇应该都能给到一些思路。

1. 这个报错到底在说什么

1.1 报错信息逐段拆解

先看完整报错长什么样，我用一个很常见的订单表来演示：

SELECT user_id, user_name, level, SUM(amount) FROM orders GROUP BY user_id;

这条 SQL 在 MySQL 5.6 里能跑，但到了 5.7 及以上版本，大概率直接报：

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

这段信息看着长，关键点其实就四个：

• ERROR 1055是错误码，(42000)是 SQLSTATE 类别编号，后者可以不用管。
• Expression #2告诉你出问题的是 SELECT 列表里的第 2 个字段，也就是user_name。这个编号是 1 开始的，数到几就是第几个字段。
• not in GROUP BY clause说明这个字段没出现在 GROUP BY 里。
• contains nonaggregated column说明它不是聚合函数（SUM、COUNT、MAX 这些）包出来的结果，是一个"裸"出来的原始字段。
• not functionally dependent on columns in GROUP BY clause这句最核心，意思是数据库认为这个字段跟 GROUP BY 的字段之间没有"稳定的一对一对应关系"。

把这些串起来理解就一句话：你 SELECT 了一个既不在 GROUP BY 里、又不是聚合计算的字段，MySQL 不知道这个字段该取哪一条记录的值，所以拒绝执行。

1.2 最容易触发这个错的几个场景

根据我自己的实战经验，1055 报错高发的场景非常典型：

第一，统计报表类的查询。比如按用户分组统计消费总额，同时还想带出用户名、用户等级、注册时间这些"附属字段"。这是最典型的翻车场景，因为报表查询几乎必然要 SELECT 一些非聚合字段。

第二，分组字段和排序列不一致。比如按user_id分组，但ORDER BY create_time，那么create_time也得处理，否则同样报错。

第三，视图或子查询里做了分组，外层恰好引用了没被分组的列。这种隐蔽性更强，因为报错可能指向外层查询的某个字段，但问题根源在内层。

第四，DISTINCT 和 GROUP BY 混用。有些老代码为了去重把两个语法叠一起用，这种 SQL 在 5.6 里没事，在 5.7 里经常一起爆出来。

记住一个规律：只要 SELECT 列表里出现"非聚合的普通字段"，并且这个字段跟 GROUP BY 字段之间没有主键级别的绑定关系，1055 就会找上门。

2. 为什么 MySQL 非要"多管闲事"

2.1 SQL_MODE 是什么

要理解 1055 的根源，必须先明白sql_mode是什么。它是一组 MySQL 运行时的"行为开关"，决定了服务器在哪些场景下严格报错、哪些场景下睁一只眼闭一只眼。你可以通过下面的 SQL 直接查看当前环境用的什么模式：

SELECT @@sql_mode;

在我本机的 MySQL 8.0 环境里，默认值长这样：

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

重点看我加粗的第一个：ONLY_FULL_GROUP_BY。这个开关从 MySQL 5.7 开始默认开启，而 5.6 及更早的版本默认是关闭的。这就是为什么同样是GROUP BY user_id然后 SELECTuser_name，5.6 能跑、5.7 直接报错。

MySQL 官方文档说了，ONLY_FULL_GROUP_BY的存在是为了保证查询结果符合 SQL 标准语义。GROUP BY user_id之后，结果集里每个user_id只有一行，那一行里的user_name应该是哪个？如果分组内有多个不同的user_name，取第一个？取随机一个？取最大的？你根本说不清规则，查出来的数据自然也就有"不确定性"。

2.2 5.6 时代到底做了什么

MySQL 5.6 以及更早的版本，遇到这种情况的处理方式简单粗暴：随便挑一行返回，然后不管你。听起来好像很爽，但实际使用中这就是个数据大坑。我在一家公司做数据报表的时候曾经踩过一次：按商品类目分组统计销量，顺手 SELECT 了一个商品名称，当时 5.6 跑出来"看起来没问题"，结果后面复盘发现部分类目下的商品名称跟实际对不上——因为它取的是分组内的任意一行，而不是你心里想的"那一行"。这还不是最可怕的，最可怕的是这种错误往往悄无声息，不上线评审根本发现不了。你拿一份看似正确实则随机的报表去做商业决策，风险有多大不用我说了吧。

所以ONLY_FULL_GROUP_BY的开启，本质是 MySQL 在帮你拦截这种"无意识的不确定性"，逼着你在写 SQL 的时候就明确告诉数据库：这个字段到底该怎么取。

2.3 函数依赖：报错里的"一线生机"

报错信息里有一句which is not functionally dependent on columns in GROUP BY clause，这里有一个反常识的好消息：如果字段跟分组字段之间存在"函数依赖"（Functional Dependency），那么即使它不在 GROUP BY 里，MySQL 也允许你 SELECT。

函数依赖的意思是：只要确定了分组字段的值，另一个字段的值就是唯一确定的。最典型的场景就是主键。举个例子：

SELECT user_id, user_name, level, SUM(amount) FROM orders INNER JOIN users ON orders.user_id = users.id GROUP BY users.id;

如果users.id是主键，那么user_name和level都因为users.id唯一而变成"函数依赖"的字段。这种情况下 MySQL 5.7+ 能自动识别出依赖关系，上面的查询可以正常通过，即使user_name和level没有出现在 GROUP BY 里。

这一点非常实用，很多人不知道。如果你 GROUP BY 的是主键，附带字段是可以名正言顺地直接 SELECT 的。但注意，MySQL 的函数依赖检测是有限的，它只认主键、唯一键这类声明过的约束，不会去猜测"我觉得这两个字段应该有对应关系"。所以如果分组字段不是主键/唯一键，就把要显示的字段老老实实加进 GROUP BY，或者用聚合函数包起来。

3. 五种解决方案，按推荐程度排序

3.1 方案一：把漏掉的列补进 GROUP BY

最正规、最符合 SQL 标准的做法就是让 SELECT 列表里的非聚合字段全部出现在 GROUP BY 里：

SELECT user_id, user_name, level, SUM(amount) FROM orders INNER JOIN users ON orders.user_id = users.id GROUP BY user_id, user_name, level;

这样做的逻辑是：既然你要按user_id分组，又想把user_name和level一起展示出来，那就把分组粒度放大到这三个字段的组合。只要这三个字段在同一个分组内始终保持一致，查询结果就是确定的、可解释的。

代价自然也有：分组字段变多，分组粒度变细，SUM(amount)的聚合范围也被拆得更细了。原本一个user_id一行，现在可能变成user_id + user_name + level多行。如果user_name或level在不同订单里内容不同（比如用户改了昵称、等级变了），那同一个用户就会拆成多行。这个方案只适合那些"字段跟着分组键走、不会变化"的场景，一定要想清楚再下手。

3.2 方案二：用 ANY_VALUE() 明确"随便取一个"

MySQL 5.7.5 开始提供了ANY_VALUE()函数，语义就是告诉数据库：我知道这个字段可能有多个值，但我现在不关心取哪个，你随便给我一个就行。

SELECT user_id, ANY_VALUE(user_name) AS user_name, ANY_VALUE(level) AS level, SUM(amount) FROM orders INNER JOIN users ON orders.user_id = users.id GROUP BY user_id;

相比于把字段加进 GROUP BY，ANY_VALUE()的好处是不改变分组粒度，聚合结果跟原来保持一致。它本质上是把 5.6 时代的"随便取一行"行为显式地写出来了——不一样的是，这次是开发者自己决定承担不确定性，而不是 MySQL 偷偷帮你做决定。

使用这个函数要认清楚一个适用前提：你确实不在乎这个字段取哪条记录的值。举例来说，按用户分组统计订单总额，附带一个用户昵称，而你觉得昵称大不了取某一个订单里的值就够了，那就用ANY_VALUE()。但如果你想展示的是"用户最新的昵称"或者"下单时用户所在等级"，那这个函数就不合适了，你应该去用关联子查询或者窗口函数。这中间的取舍，一定要在业务层面想清楚。

3.3 方案三：用 MAX()/MIN() 等聚合函数包一层

如果你不希望ANY_VALUE()那种随机性，又不想改分组粒度，那就在语义上做聚合：对这个字段用MAX()、MIN()等聚合函数。比如按用户分组时要展示用户名，可以取用户名里字典序最大的那个：

SELECT user_id, MAX(user_name) AS user_name, MAX(level) AS level, SUM(amount) FROM orders INNER JOIN users ON orders.user_id = users.id GROUP BY user_id;

注意MAX(user_name)在同一个用户昵称相同的情况下返回的就是那个值，效果跟user_name没区别；但如果昵称真的存在多个版本，返回的是排序后的最后一个，至少结果是可确定的。

这种方案的适用范围比ANY_VALUE()广一些，因为它返回的结果有明确规则。实际项目中，如果你的字段值在同一分组内基本一致，用MAX()或MIN()包一下是最省事的。另一个常见变体是GROUP_CONCAT()，如果你想在分组内把多个值都列出来，比如一个用户的所有标签拼起来，它比子查询方便得多。

3.4 方案四：改 sql_mode（兜底方案，不建议长期用）

改 SQL 模式能让你回到 5.6 的宽松行为，具体有两种改法。

临时改，只对当前会话生效：

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

永久改，写入配置文件。在 MySQL 的配置文件（Linux 下通常是/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf）里，找到[mysqld]段落，加入一行：

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

然后重启 MySQL 服务使配置生效。

但我必须给出一个明确的建议：这个方案只能用来临时止血，千万不要当成长期的解决方案。原因有两点。

第一，1055 报错本身就是在提醒你 SQL 写得有歧义。你把报错关掉，不等于歧义消失了，只是把问题从"报错"变成了"返回不确定的结果"。这在同一个团队里特别危险：你关掉了模式，同事用 Navicat 连上去也查不出问题，但线上跑出来的数据可能对错参半，而且这种数据错误极难定位。

第二，团队里如果有新人接手，他们默认会认为 MySQL 的宽松行为是正常的，写出来的 SQL 在其他 5.7+ 环境里直接跑不通，代码可移植性几乎为零。我见过不止一个项目为了省事关掉ONLY_FULL_GROUP_BY，后来换机器、升级环境、新同事搭本地库，全都在报错上卡壳，最后还是要回来补 SQL，省的事全得加倍还回去。

如果真的是历史遗留项目、几千条 SQL 一时改不完，我的建议是：先全局关掉模式紧急恢复线上，同时开一个专项任务慢慢梳理改造，全部改完之后再把模式打开。注意排查的时候要按线上真实的 sql_mode 跑，别只凭记忆猜。

3.5 方案五：用派生表或子查询封装

某些场景下，你需要的字段并不是分组字段本身，而是分组内"某一行"的属性，这时候用派生表（Derived Table）更合理。比如你要按用户分组统计消费总额，同时展示用户最近一笔订单的下单时间：

SELECT o.user_id, u.user_name, t.total_amount, t.last_order_time FROM ( SELECT user_id, SUM(amount) AS total_amount, MAX(order_time) AS last_order_time FROM orders GROUP BY user_id ) t INNER JOIN users u ON t.user_id = u.id LEFT JOIN orders o ON o.user_id = t.user_id AND o.order_time = t.last_order_time;

这里内层先做聚合统计，外层再通过 join 把需要的字段补回来。逻辑上非常清晰，而且每个字段的取值规则都是确定的。缺点是 SQL 结构复杂了一些，写的时候容易顺手把ON条件写错，导致数据重复。我在实际项目里用这种方案解决了不少"既要聚合、又要明细"的矛盾场景，只要你能接受多一层嵌套，它可以说是最严谨的解法。

还有一个类似的思路是窗口函数（Window Function）。MySQL 8.0 支持ROW_NUMBER()、FIRST_VALUE()这些，配合子查询可以精准拿到分组内满足特定条件的记录。这个方案最灵活，但要求数据库版本是 8.0 或更高，而且对执行计划的复杂度有一定影响，查询量大的时候要注意压测。

4. 一次真实排障记录与踩坑复盘

4.1 从报错到定位的完整过程

去年我在一个电商后台项目里做过一次典型的 1055 排障，过程很有代表性，分享出来给大家做个参考。当时线上某个运营后台的订单统计接口突然开始报 500，日志里就是 1055 错误。奇怪的是这个接口运行大半年了，之前一直很稳定。为什么突然挂了？

排查的第一步，我先确认数据库是不是切换过环境。查了一下才发现，原来项目刚做了一次整库迁移，从一台旧服务器迁到了新集群，而新集群用的是 MySQL 5.7，旧服务器是 5.6。代码一行没改，但默认的sql_mode变了，原来能跑的 SQL 在 5.7 的严格模式下面直接失效。

定位到问题之后就简单了。我当时把那条接口执行的 SQL 原样拉出来看，它长这样：

SELECT o.order_status, u.user_name, COUNT(*) AS order_count FROM orders o LEFT JOIN users u ON o.user_id = u.id GROUP BY o.order_status ORDER BY o.order_status;

一眼就能看出问题：u.user_name既不在 GROUP BY 里，也不是聚合函数的结果。按一个订单状态分组，组内可能关联到多个用户，取哪个用户名完全没依据。虽然这个 SQL 在 5.6 下跑得欢，但它本质上是"有缺陷的代码碰上了宽松的环境"。

4.2 我踩过的三个关键坑

第一个坑，是改了sql_mode但连接不生效。那次我先通过客户端执行了SET GLOBAL sql_mode = ...，结果应用还是继续报 1055。原因很简单：应用连接池里的连接是之前建立的，它们保存的还是旧的会话变量。SET GLOBAL只对新建立的连接生效。要么重启应用，要么让连接池主动回收旧连接，否则改了半天等于白改。

第二个坑，配置文件修改在了错误的段落下。自己在/etc/my.cnf里找了一圈，把sql_mode加在了文件顶部，结果重启服务之后模式没变。为什么？因为 MySQL 只认[mysqld]段里的配置，写在[client]或者[mysql]段里都不会对服务端生效。看起来是个小问题，但在紧急排障那种状态下，白折腾了二十多分钟。

第三个坑，也是最容易忽视的：改了模式只是把报错藏起来了，数据可能已经错了。那次我为了临时恢复线上，把新集群的sql_mode关掉了。过了一天再检查某些统计口径，发现部分数据跟旧服务器对不上。因为宽松模式下，同样的GROUP BY查询可能随机取不同的行，新旧环境查出来的值不一致。最后我们的处理方式不是"改回模式"，而是把相关统计 SQL 全部重写成严格模式兼容的版本，然后再把ONLY_FULL_GROUP_BY重新打开。

经过这几次折腾，我现在定了一条团队的硬性规矩：所有涉及GROUP BY的查询，上线前必须在一台开启ONLY_FULL_GROUP_BY的 MySQL 5.7 及以上环境里跑一遍。本地开发可以用 Docker 直接起一个：

docker run --name mysql-test -e MYSQL_ROOT_PASSWORD=yourpassword -d mysql:5.7

用这套环境跑过一遍没报错，再上别的环境基本不会出幺蛾子。

5. 常见问题速查与排查套路

5.1 高频报错场景对照表

这张表基本上覆盖了我碰到过的绝大多数情况。有一条值得单列出来讲，就是视图和存储过程。它们的问题最隐蔽：创建视图的时候如果环境是宽松模式，定义就能成功；后来环境变严格了，查询视图时才报 1055。这种报错往往让人觉得莫名其妙，因为你查的是一个视图，并非自己手写的 SQL。处理办法是拿到视图的定义语句，重新梳理它的 SELECT 列表，把非聚合字段处理一遍，然后DROP VIEW再CREATE VIEW，或者用CREATE OR REPLACE VIEW。

5.2 高效排查四步走

遇到 1055 报错，我建议按照这个顺序排查，能省不少时间：

第一步，先把报错信息里的Expression #N看清楚，N 对应 SELECT 列表的第几个字段。这一步能直接锁死目标字段，避免在一大段 SQL 里大海捞针。

第二步，分析这个字段跟 GROUP BY 字段的关系。如果分组字段是主键或唯一键，确认函数依赖是否成立；不是的话就直接进入第三步。

第三步，根据业务语义选方案。字段值在同一分组内必然相同，就补进 GROUP BY；不关心取哪个就用ANY_VALUE()；需要明确的取值规则就用聚合函数或子查询。

第四步，修改后在严格模式下执行一遍，确认不报错，再把 SQL 提交到代码评审。这一步不能跳过，尤其注意别在自己的 5.6 本地库上测试，那样测不出任何 1055 问题。

5.3 关于新老版本的额外提醒

MySQL 8.0 比 5.7 更严格的地方不止ONLY_FULL_GROUP_BY一个。8.0 默认还有STRICT_TRANS_TABLES，以及一组关于整数显示宽度、时区处理的行为变化。我遇到过有人把 5.7 的标准 SQL 迁到 8.0 后又出现新报错的情况，报错信息单独看没问题，拼在一起才发现是老的sql_mode没带齐。如果你要跨大版本升级数据库，记得先统一两边环境的sql_mode再做全量 SQL 回归测试，别只盯着 1055 一个错误。

还有一个容易被忽略的点：MySQL 对函数依赖的检测是"字面级"的。就算user_name在业务逻辑上确实由user_id唯一决定，只要表结构里没建唯一索引或主键，MySQL 就不会认为它函数依赖成立。想在数据库层面把这个关系表达清楚，最简单的做法是给users.id加上主键或唯一索引。反过来也提醒我们，表设计阶段把主键和唯一键规划好，能省掉后面大量改 SQL 的功夫。

最后再说几句操作层面的经验

我自己现在写聚合查询，脑子里会默认过一遍这个清单：SELECT 列表里出现的每一个非聚合字段，我要么把它放进 GROUP BY，要么包一层聚合函数，要么明确它跟分组键存在函数依赖，否则绝不提交。这个习惯帮我挡掉了至少十几次线上事故，包括很多不太容易第一时间发现的"看起来能跑"的 SQL。

如果你所在项目里大量 SQL 已经"带病运行"，我的建议是别试图一次性全部改完，那样风险太高。按接口或报表模块拆成小批次，每一批改完都在严格模式下回归测试，同时对比改前改后的聚合结果，确认数据一致，再继续下一批。整个过程不要开新的ONLY_FULL_GROUP_BY豁免，一旦开了，回归就失去了意义。

另外记得排查手法上多用EXPLAIN看看执行计划。很多时候 1055 只是表象，背后可能是索引设计不合理、关联顺序有问题导致的大查询。把 SQL 写规范了、执行计划看明白了，你会发现这类报错的排查速度会快很多。报错不可怕，可怕的是用关掉检查的方式来"解决"报错，那才是给自己埋雷。