mysql 5.7.5+默认启用only_full_group_by模式，要求select字段必须在group by中或使用聚合函数，否则报错；这是对sql标准的回归，旨在消除分组查询结果的不确定性。

这个错误不是SQL写错了，是MySQL变“较真”了——从5.7.5起默认启用ONLY_FULL_GROUP_BY模式，强制要求：SELECT里的每个字段，要么出现在GROUP BY子句中，要么必须套在聚合函数里（如MAX()、ANY_VALUE()），否则直接报错。

为什么旧SQL在新MySQL里突然报错

旧版MySQL（如5.6）对GROUP BY比较宽松，允许你写：SELECT name, age FROM user GROUP BY dept_id。它会“随便挑一条”dept_id组内的name和age返回，结果不可预测。5.7.5+开启ONLY_FULL_GROUP_BY后，MySQL拒绝这种模糊行为，因为name和age既没参与分组，也没聚合，数据库无法保证每次返回同一值。

• 典型报错信息里关键部分：Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'db.table.name'
• 本质是SQL标准（SQL92）的回归，不是bug，是防误用
• 升级MySQL版本（尤其是5.6→5.7/8.0）或换用云数据库时最常触发

如何快速判断是不是这个原因

登录MySQL执行这条命令，看输出是否含ONLY_FULL_GROUP_BY：

SELECT @@global.sql_mode;

如果返回结果类似ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,...，那就确认了。注意区分@@global.sql_mode（全局）和@@session.sql_mode（当前连接），后者可能被临时改过但不持久。

• 云数据库（如阿里云RDS、腾讯云CDB）通常不开放SET GLOBAL权限，只能靠改SQL或申请控制台配置
• 本地Docker环境可能每次重启丢失SET设置，得写进my.cnf才稳定
• SHOW VARIABLES LIKE 'sql_mode';效果同SELECT @@sql_mode;，但更直观

SELECT里混用非分组字段的三种处理方式

核心原则：让MySQL明确知道你“要什么”，而不是让它猜。

• 加聚合函数——最安全：用MAX(name)、MIN(created_at)等，语义清晰，适合取极值场景
• 用ANY_VALUE(name)——最直白：显式声明“我就要组内任意一个值”，MySQL 5.7.5+原生支持，不改变逻辑
• 补全GROUP BY字段——最彻底：比如原查GROUP BY user_id，但还要order_id，就改成GROUP BY user_id, order_id；前提是这些字段在业务上确实构成自然分组维度

别硬套GROUP_CONCAT()来“绕开”，除非真需要拼字符串；也别盲目删ONLY_FULL_GROUP_BY，它能帮你揪出隐藏的数据歧义问题。

临时禁用 vs 永久修改 sql_mode 的坑

临时执行SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,...';看似快，但有硬伤：

• 需要SUPER权限，很多生产环境禁止授予
• MySQL重启后失效，Docker容器重建等于白设
• 影响所有连接，可能让其他依赖严格模式的应用出问题

永久改配置（如/etc/my.cnf里加sql_mode=STRICT_TRANS_TABLES,NO_ZERO_DATE,...）虽稳，但上线前必须验证：云数据库可能不支持，某些PaaS平台只允许通过控制台开关，且修改后必须重启实例——这在高可用系统里要走变更流程。

真正容易被忽略的点是：即使你改了sql_mode，老SQL里那些“随机取值”的逻辑依然存在，只是错误被掩盖了。下次数据分布变化或索引调整，结果可能突变。所以优先修SQL，再考虑调配置。