MySQL 8.0 里执行 GROUP BY 报错，这还真不是你的 SQL 写错了——而是数据库开始严格执行 SQL 标准了。说白了，默认启用了 ONLY_FULL_GROUP_BY 模式。只要 SELECT 的字段列表里出现了一个非聚合字段（比如 id 或 name），而这个字段又没出现在 GROUP BY 子句中，MySQL 就直接给你甩个报错，一点不含糊。
不过别慌，问题不难定位，解法也不止一种。这里先给一个核心判断：确认报错根源，先看错误信息。
怎么确认是不是 ONLY_FULL_GROUP_BY 导致的报错
排查其实就两步。第一步，看错误信息里有没有这串关键词——Expression #1 of SELECT list is not in GROUP BY clause，或者更直白的 this is incompatible with sql_mode=only_full_group_by。第二步，查当前模式：
- 直接跑
SELECT @@SESSION.sql_mode;，结果里只要包含ONLY_FULL_GROUP_BY，那问题就是它了。 - 但如果用的是云数据库（像阿里云 RDS），千万别以为
SELECT @@GLOBAL.sql_mode;能改。这玩意只能看，不能写——大部分云厂商压根不开放全局参数的编辑权限。 - 还有个小坑：输出结果是个以逗号和空格分隔的字符串，例如
'ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES,'。你配置my.cnf时，多一个空格或单引号，MySQL 都会直接启动失败。格式敏感，不容马虎。
临时绕过：只对当前连接生效
这个方法最安全，也最适合开发调试或 CI 流水线——断开连接就恢复了，可以说是最安全的绕行方案。用这条命令：
SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode, 'ONLY_FULL_GROUP_BY', ''));千万别自己手拼字符串。因为少一项，MySQL 会“贴心”地自动补回默认值，你辛辛苦苦改的等于白费。这条命令也不能塞进 JDBC 的 connectionInitSql——部分驱动在建连后立刻执行 autocommit 检查，导致这条设置被忽略。要在应用首次 query 之前显式执行。另外，SET SESSION sql_mode = '' 是无效的，空值会被 MySQL 自动还原回完整默认集，ONLY_FULL_GROUP_BY 原封不动还在那里。
永久修改：改配置并重启（仅限自建 MySQL）
生产环境如果必须关掉这个模式，这是唯一可靠的方式。但格式的容错率极低：
- 编辑
/etc/mysql/my.cnf（Linux）或my.ini（Windows），在[mysqld]段下加一行：
sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION - 注意了：必须严格按这个顺序写，不允许任何空格、单引号或换行。漏了一项或多一个空格，MySQL 都可能无法正常启动。
- 改完后执行
sudo systemctl restart mysql，再用SELECT @@GLOBAL.sql_mode;验证。 - 云数据库的配置走控制台「参数模板」，你懂的——部分厂商的模板根本没开放
sql_mode编辑权限。
为什么更推荐重写 SQL 而不是关模式
关掉 ONLY_FULL_GROUP_BY 后，MySQL 依然会从每组中“任意选一行”返回非聚合字段的值。这个“任意”取决于存储顺序、执行计划甚至索引的变化——下次查同样的数据，结果可能完全不同。真正的解法，从来都是重写 SQL，而不是关闭检查：
- 如果只需要统计，直接删掉冗余字段：
SELECT dept_id, COUNT(*) FROM user GROUP BY dept_id; - 如果真需要带一个
name字段展示，且不在乎具体是哪个值（比如展示一组里的任意示例），用ANY_VALUE(name)：
SELECT dept_id, ANY_VALUE(name), COUNT(*) FROM user GROUP BY dept_id;
这个ANY_VALUE()函数从 MySQL 5.7.5 起就支持了。 - 如果
dept_id和dept_name本来就是一对应的关系，直接把dept_name加进GROUP BY子句就行：GROUP BY dept_id, dept_name。
最容易被忽略的一点是：即使关了 ONLY_FULL_GROUP_BY，结果仍然是不可控的——它只是让错误的 SQL “能跑起来”，而不是让结果变正确。
