游乐游手机版
首页/数据库/文章详情

MySQL5.7版本数据库sql_mode参数only_full_group_by配置问题的详细解决方法

时间:2026-07-25 19:28
线上服务器数据库查询使用了 GROUP BY 竟然报出以下错误 1055 - Expression 1 of SELECT list is not in GROUP BY clause and contains nonaggregated column csc_risk a DefaultDat

线上服务器数据库查询使用了 GROUP BY 竟然报出以下错误

1055 - Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'csc_risk.a.DefaultDate' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by, Time: 0.035000s

将部分数据迁移到本地进行测试时,发现同样的 SQL 语句居然可以正常执行。这就有点意思了——问题到底出在哪里呢?

先来查看本地数据库的版本:

SELECT VERSION()

MySQL5.7版本sql_mode=only_full_group_by问题及解决过程

再检查一下线上数据库的版本,发现同样是 5.7 版本。

5.7.24

原因分析

MySQL 5.7 版本默认启用了 sql_mode = only_full_group_by 属性,正是这个属性导致了上述报错。知道了原因就好办了——接下来就是如何解决它。

在默认安装的 MySQL 5.7.x 版本中,only_full_group_by 模式是开启的。一旦开启,你会发现 group by 的使用变得非常严格:它只能返回分组字段本身,而不能直接返回其他非分组字段。换句话说,group by 几乎变成了 distinct 的加强版,功能范围一下子缩小了很多。

不过,这个模式开启也有其优点——MySQL 提供了一个 any_value(field) 函数,它允许非分组字段出现在 SELECT 中,效果与关闭 only_full_group_by 相同。因此,如果你不想关闭该模式,也可以考虑使用这个函数来实现兼容。

1、查看当前的 sql_mode

SELECT @@sql_mode;

查询出来的结果大致如下:

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

2、去掉 ONLY_FULL_GROUP_BY,重新设置

SET @@global.sql_mode ='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

3、对于已存在的数据库,还需要单独设置

上述全局设置只对新创建的数据库生效。对于已经存在的数据库,需要在对应的数据库中执行以下命令:

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

注意:以上方式仅作为临时解决方案,数据库重启后就会失效。

修改 MySQL 配置文件(永久生效)

在 Linux 系统下修改 my.cnf,在 Windows 系统下修改 my.ini。在 [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 报错时,可以从两个方向入手:要么临时关闭该模式,要么修改配置文件使其永久生效。另外,使用 any_value() 函数也是一种优雅的兼容方式。希望这个排查过程能为你提供一些参考。

来源:https://www.jb51.net/database/368055wfe.htm
上一篇KingbaseES的SQL慢查询优化实战:物化视图、QueryMapping与函数缓存详解 下一篇Hive Beeline 能否执行复杂查询全面解析
本站内容用于信息整理与展示,如有侵权或内容问题请及时联系处理。

相关推荐

补充同频道和同主题内容,方便继续浏览更多相关内容。

同类最新

继续查看同栏目最近更新的文章。

更多
自增主键值从何而来?深入理解原理,告别只会auto_increment
数据库 · 2026-07-25

自增主键值从何而来?深入理解原理,告别只会auto_increment

KingbaseES推荐使用serial、bigserial、显式sequence或identity列实现自增主键。serial创建integer并关联序列,bigserial对应bigint;显式sequence可自定义起始值等参数;identity有generatedbydefault(允许指定值)与always(禁止)两种模式。

Linux下瀚高数据库授权文件过期及替换解决方案
数据库 · 2026-07-25

Linux下瀚高数据库授权文件过期及替换解决方案

在银河麒麟系统下,瀚高数据库hgdb-4 5试用授权20天到期后需替换正式授权文件。正确操作:停止服务,备份旧文件,将授权文件复制到 opt highgo hgdb-4 5 etc lic 并命名为hgdb lic,设置权限600和属主highgo:highgo,再启动服务。禁止直接修改data目录下的license info文件。

Oracle BLOB实时同步的5大技术挑战与难点解析
数据库 · 2026-07-25

Oracle BLOB实时同步的5大技术挑战与难点解析

OracleBLOB实时同步面临分片组装、多列隔离、长事务跨窗口、事务回滚及大对象资源控制等技术挑战,必须在日志中精确还原完整字段值,才能保证源端与目标端数据完全一致,这对同步系统的稳健性提出了高要求。

MySQL禁用redo日志导致全备失败
数据库 · 2026-07-25

MySQL禁用redo日志导致全备失败

MySQL全量备份失败是由于数据定义语言操作触发排序索引构建,禁用重做日志导致XtraBackup无法获取一致性备份。测试验证表明,优化表语句即使无数据也会触发该问题。根本原因在于排序索引构建过程跳过了重做日志记录,破坏了备份的一致性。

Kafka架构图优化与改进的全面详细步骤与实践指南
数据库 · 2026-07-25

Kafka架构图优化与改进的全面详细步骤与实践指南

Kafka作为实时数据流处理的核心中间件,其底层架构虽已相当成熟,但在实际生产环境中,要充分发挥其性能潜力,仍需落实到具体的调优与架构改造上。核心目标可归纳为三点:如何承载更高的吞吐量、如何保障数据不丢失、以及故障发生时如何快速恢复。本文将从这几个关键方向出发,深入探讨如何真正榨干Kafka集群的性