这不是 bug，是 MySQL 5.7+ 主动校验语义合法性——GROUP BY 查询中非聚合字段必须显式声明取值逻辑，可通过 SELECT @@GLOBAL.sql_mode 检查是否启用 ONLY_FULL_GROUP_BY，用 ANY_VALUE() 或补全 GROUP BY 可合法解决，而直接关闭该模式会导致结果不可预测。
直接结论：这不是 bug，是 MySQL 5.7+ 主动校验语义合法性 —— 你写的 GROUP BY 查询本身存在歧义，必须明确告诉 MySQL 每个非聚合字段的取值逻辑。
怎么看当前是否触发了 ONLY_FULL_GROUP_BY 限制
连上 MySQL 后执行：SELECT @@GLOBAL.sql_mode;，如果返回值里包含 ONLY_FULL_GROUP_BY（通常在最前面），就确认启用了该限制。注意：@@SESSION.sql_mode 可能不同，临时修改只影响当前连接。
为什么加了 ANY_VALUE() 就不报错了
ANY_VALUE() 是 MySQL 5.7+ 提供的显式语义声明函数，它告诉优化器：“我知道这个字段没参与分组，也和 GROUP BY 列没有函数依赖关系，但我只要任一匹配行的值就行”。它不是绕过检查，而是合法地满足检查要求。
- 用法示例：
SELECT user_id, ANY_VALUE(username), COUNT(*) FROM logs GROUP BY user_id; - 不能滥用：
ANY_VALUE()返回的是“任意一行”的值，不保证稳定或业务意义 —— 如果业务上要求取最新/最早/最大值，该用MAX()、MIN()或子查询 - 性能无额外开销，但语义责任完全落在开发者身上
改 sql_mode 是最快的，但代价是什么
执行 SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'; 确实能立刻让旧 SQL 跑通，但隐患明显：
- MySQL 会退回到“随机选一行值”的行为，结果不可预测（比如
SELECT name, age FROM user GROUP BY dept中的name可能每次查都不一样） - 云数据库（如阿里云 RDS）需进控制台参数设置页修改，且修改后必须重启实例才生效
- 本地自建 MySQL 修改
/etc/my.cnf或my.ini后，必须重启 mysqld 进程，否则不生效
ORDER BY 里引用非 GROUP BY 字段也会报错
很多人只注意 SELECT 列，忽略 ORDER BY 和 HAVING 同样受限制。例如：SELECT dept, COUNT(*) FROM emp GROUP BY dept ORDER BY hire_date DESC; 会报错，因为 hire_date 未出现在 GROUP BY 中，也不在函数依赖链上。
- 正确做法：要么补进 GROUP BY（
GROUP BY dept, hire_date），要么用聚合函数（ORDER BY MAX(hire_date)），要么用ANY_VALUE(hire_date) - 注意：MySQL 5.7.5+ 支持函数依赖推断（比如主键列自动满足依赖），但仅限于明确的主外键或唯一约束场景，别指望它自动猜中业务逻辑
真正容易被忽略的是：即使你用 ANY_VALUE() 写对了，如果后续换到 PostgreSQL 或严格模式的 MariaDB，这套写法依然不兼容 —— 所以最稳妥的长期解法，是把业务逻辑里“想取哪个值”的意图，明确转成聚合函数或关联子查询。
