确认方法是执行SELECT @@sql_mode，若结果包含ONLY_FULL_GROUP_BY即为该模式导致；其强制要求SELECT中非聚合列必须出现在GROUP BY中或被聚合函数包裹，否则报错1055。
不是语法错，是 MySQL 5.7+ 默认启用了 ONLY_FULL_GROUP_BY 模式，它拒绝执行“语义不明确”的 GROUP BY 查询——比如 SELECT id, name FROM user GROUP BY status 这类语句，id 和 name 不在 GROUP BY 中，也没被聚合函数包裹，MySQL 不知道该返回哪一行的值。
怎么确认真是 ONLY_FULL_GROUP_BY 在作怪
在 phpMyAdmin 的 SQL 窗口里直接执行：
SELECT @@sql_mode;
如果返回结果里包含 ONLY_FULL_GROUP_BY（通常排最前，逗号分隔），就是它。别只看错误信息里带 “syntax error”，phpMyAdmin 的报错标题常误导人，真实错误码是 1055，不是 1064。
注意：云数据库（如阿里云 RDS）可能禁止改 @@GLOBAL.sql_mode，SET GLOBAL 会直接报 ERROR 1227，只能动会话级或 SQL 本身。
立即学习“PHP免费学习笔记（深入）”；
为什么改了 GROUP BY 还报错
常见误操作包括：
- 只补了部分字段，比如原语句是
SELECT a, b, c, COUNT(*) FROM t GROUP BY a，只加了b进去：GROUP BY a, b，但c还没处理——必须全部非聚合列都出现或被包裹 - 用了别名但 GROUP BY 写的是原始列名，或反过来；MySQL 8.0+ 不允许在
GROUP BY里用SELECT别名（除非开sql_mode中的ANSI_QUOTES，不推荐） - 表里有主键但没被放进
GROUP BY，误以为“有主键就自动函数依赖”——其实只有主键本身出现在GROUP BY时，其他列才被视为依赖；GROUP BY status不能推导出id唯一
临时绕过但别上线的写法
仅限调试或本地验证，不要放进生产代码：
SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));
执行完再跑你的 GROUP BY 语句。这条命令安全，断开连接即失效，不影响其他会话。但要注意：
- 别手拼
sql_mode字符串，漏项会导致其他校验失效（比如STRICT_TRANS_TABLES） - JDBC 连接串里的
connectionInitSql可能不生效，得在应用第一次 query 前显式执行 - phpMyAdmin 每次新开 SQL 标签页都是新会话，这句得重输
真正要命的点不是报错本身，而是很多人修完 SQL 后没验证结果逻辑——比如用 ANY_VALUE(name) 看似跑通了，但下次查出来的是另一行的 name，业务上是否可接受？这个不确定性，在升级前后行为不一致，最容易埋雷。
