MySQL 8.0 GROUP BY报错主因是默认启用ONLY_FULL_GROUP_BY模式，要求SELECT中非聚合列必须出现在GROUP BY子句或用ANY_VALUE()等显式处理；可临时会话级调整、永久配置文件修改或重写SQL适配标准。
MySQL 升级到 8.0 后 GROUP BY 报错，基本就是 ONLY_FULL_GROUP_BY 模式在起作用——它不是 bug，是 MySQL 开始按 SQL 标准执行了。直接关掉它最省事，但结果可能每次都不一样；改 SQL 才是真正可控的解法。
怎么看报错是不是 ONLY_FULL_GROUP_BY 导致的
错误信息里只要出现这两段之一，就 100% 是它：
-
Expression #N of SELECT list is not in GROUP BY clause（#N 表示第 N 个字段） this is incompatible with sql_mode=only_full_group_by
再确认一下当前会话模式：
SELECT @@SESSION.sql_mode;
返回结果里如果含 ONLY_FULL_GROUP_BY（通常在开头），就没跑。注意：云数据库如阿里云 RDS 一般不让你改 @@GLOBAL.sql_mode，SELECT @@GLOBAL.sql_mode 只能看，不能信它可写。
优先改 SQL：用 ANY_VALUE() 显式表达意图
ANY_VALUE() 不是“随便取一个”，而是告诉 MySQL：“我清楚这列在组内不唯一，不确定性我来担”。比硬塞进 GROUP BY 更轻量，也比关模式更安全。
- 原报错语句：
SELECT id, name, COUNT(*) FROM user GROUP BY status - 改成：
SELECT ANY_VALUE(id), ANY_VALUE(name), status, COUNT(*) FROM user GROUP BY status
注意点：
-
ANY_VALUE()要求 MySQL ≥ 5.7.5；低版本只能补全GROUP BY或用子查询 - 如果业务真依赖“最新创建的 id”或“最大 price”，
ANY_VALUE()就不合适，得用窗口函数或关联子查询重写 - 它不会自动走索引优化，大表分组时可能拖慢查询
临时绕过：只对当前连接生效，最安全
开发调试、CI 流水线跑通、或快速验证问题根源时用它，断开重连就自动恢复，不影响其他连接。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode, 'ONLY_FULL_GROUP_BY', ''));
关键细节：
- 别手拼字符串，比如
SET SESSION sql_mode = 'STRICT_TRANS_TABLES,...'—— 漏一项 MySQL 就自动补回默认集，ONLY_FULL_GROUP_BY还在 -
SET SESSION sql_mode = ''是无效的，空值会被 MySQL 自动还原为完整默认集 - JDBC 的
connectionInitSql里写这句大概率被忽略，得在应用首次query前显式执行
永久修改配置：仅限自建 MySQL，且格式容错率极低
云数据库（如阿里云 RDS、腾讯云 CDB）基本不开放配置文件编辑权限，只能走控制台「参数模板」，而且部分厂商模板根本不允许改 sql_mode。
自建 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 可能无法启动。改完重启服务，再用 SELECT @@GLOBAL.sql_mode; 验证。
复杂点在于：哪怕你加了主键进 GROUP BY，如果表没定义主键或唯一约束，MySQL 8.0 仍可能拒绝——它认的是函数依赖关系，不是你“觉得应该一致”。这点最容易被忽略。
