mysql 5.7+ 默认启用 only_full_group_by，要求 select 中非聚合字段必须出现在 group by 中，否则报错 error 1055；推荐使用 any_value() 显式表达语义，或重写为聚合/窗口函数，而非简单禁用该模式。
MySQL 5.7+ 默认启用 ONLY_FULL_GROUP_BY，不是你的 SQL 写错了，而是数据库开始强制执行 SQL 标准——SELECT 列表里所有非聚合字段，必须显式出现在 GROUP BY 中，否则直接报错 ERROR 1055。绕过它不难，但选哪种方式，取决于你是在调试、上线还是长期维护。
为什么 SET SESSION sql_mode = ... 有时会失效
很多人复制网上那句 SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));，结果还是报错。原因很实际：
-
REPLACE是字符串替换，如果@@sql_mode是'STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY,NO_ZERO_DATE'，替换后变成'STRICT_TRANS_TABLES,,NO_ZERO_DATE'—— 多了个逗号，MySQL 解析失败，sql_mode实际被重置为默认值（含ONLY_FULL_GROUP_BY） - 某些客户端（如 MySQL Workbench）在连接初始化时会自动重设
sql_mode，覆盖你手动执行的SET -
SESSION级修改只对当前连接有效，应用重启、连接池重建后就没了
更稳妥的做法是：先查清当前值，再手动拼接（去掉 ONLY_FULL_GROUP_BY 及其前后逗号），例如：
SELECT @@sql_mode;
若返回 STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY,NO_ZERO_DATE，则执行：
SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_DATE';
永久修改 my.cnf 后为什么没生效
改了 /etc/my.cnf 或 my.ini 并重启 MySQL，但 SELECT @@sql_mode; 还是带 ONLY_FULL_GROUP_BY？常见原因有三个：
- 配置文件路径不对：MySQL 启动时可能读的是另一个配置文件（比如
/usr/my.cnf或~/.my.cnf），用mysqld --help --verbose | grep "Default options"确认实际加载路径 - 写错 section：必须放在
[mysqld]下，写在[client]或文件开头无效 - 未完整覆盖：
sql_mode是全量覆盖字段，不能只写sql_mode = STRICT_TRANS_TABLES，而要显式列出所有需要保留的模式（不含ONLY_FULL_GROUP_BY）
推荐写法（以 MySQL 8.0 常见默认值为例）：
[mysqld] sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
用 ANY_VALUE() 替代改配置更安全吗
是的，这是官方推荐的语义正确解法，尤其适合“每个分组里取任意一条记录的某个字段”这类场景（比如查每个 status 对应的任一 id）：
-
ANY_VALUE(id)明确告诉 MySQL：“我知道这个值不唯一，但我只要一个就行”，不破坏ONLY_FULL_GROUP_BY的语义保护 - 比关掉整个模式更细粒度，不影响其他查询的严格性
- MySQL 5.7.5+ 原生支持，无需权限变更或重启
示例：
SELECT ANY_VALUE(id) AS id, name, COUNT(*) FROM user GROUP BY name;
注意：ANY_VALUE() 不保证返回哪一行的值，如果业务依赖“最新/最早/最大”的语义，就得换成 MAX(id)、MIN(id) 或窗口函数。
生产环境禁用 ONLY_FULL_GROUP_BY 的真实风险
很多人觉得“我逻辑上确定不会出错”，就全局关掉 ONLY_FULL_GROUP_BY。但真正的问题不在这里：
- 它掩盖了 SQL 语义模糊性：比如
SELECT id, name FROM t GROUP BY status，当多个id对应同一status时，MySQL 以前随机选一个返回，现在关掉限制后依然随机——只是不报错而已 - 迁移风险：下游系统（如 BI 工具、ETL 脚本）可能依赖旧版 MySQL 行为，换到新版本或云数据库（如 AWS RDS、阿里云 PolarDB）时，默认仍开启该模式，导致突然故障
- 团队认知偏差：新人看到“能跑通”的 SQL，容易误以为这种写法是标准实践，后续复制粘贴引发更多隐性问题
真正该花时间的地方，是厘清业务意图：你要的到底是“每个分组的统计值”，还是“每个分组的代表行”——前者用聚合函数，后者用 ROW_NUMBER() + 子查询或 ANY_VALUE()，而不是一刀切地关模式。
