MySQL 5.7.5+ 默认启用 ONLY_FULL_GROUP_BY 模式导致 ERROR 1055 报错，需通过 SELECT @@sql_mode 验证；修复应基于业务意图选择删字段、扩展 GROUP BY、用 ANY_VALUE() 或聚合函数，而非简单禁用模式。
确认是否触发了 ONLY_FULL_GROUP_BY 严格模式
报错 ERROR 1055 或提示 Expression #X of SELECT list is not in GROUP BY clause，基本可以断定是 MySQL 5.7.5+ 默认启用的 ONLY_FULL_GROUP_BY 在起作用。别急着改 SQL，先验证：
- 执行
SELECT @@sql_mode;，看返回结果里是否含ONLY_FULL_GROUP_BY（通常排最前） - 云数据库如阿里云 RDS 可能禁止
SET GLOBAL，SET SESSION仅对当前连接有效 - 注意：PostgreSQL、Oracle、SQL Server 原生就拒绝这类写法，不依赖 mode 设置——它们从不妥协
修复 SQL：让非分组字段有明确语义
绕过模式检查（比如 SET sql_mode = REPLACE(@@sql_mode, 'ONLY_FULL_GROUP_BY', '')）只是掩耳盗铃，真正要解决的是“数据库不知道该选哪一行的值”。修复方向取决于业务意图：
- 如果只是要统计，删掉多余字段：
SELECT status, COUNT(*) FROM user GROUP BY status; - 如果字段和分组键逻辑一对一（如
user_id和name是主键/唯一约束），把字段加进GROUP BY：GROUP BY user_id, name - 如果接受“任取一个”，用
ANY_VALUE(name)显式表达，避免隐式行为；但注意ANY_VALUE()是 MySQL 特有，跨库迁移需重写 - 如果想取最新/最早值，用聚合函数：
MAX(created_at)、MIN(id)，比ANY_VALUE()更具可读性和确定性
HAVING 中引用未分组字段的典型错误
HAVING 是在分组后过滤，但它不能直接引用未参与分组、也未聚合的字段——这点常被忽略。例如：
SELECT dept, COUNT(*) FROM employees GROUP BY dept HAVING name = 'Alice';
会报错，因为 name 既没在 GROUP BY 里，也没被聚合。正确做法是：
- 若需按某人所在部门筛选，应先查出
name对应的dept，再在外层或子查询中过滤 - 若想查平均分超线的学生，
HAVING AVG(score) > 60才合法，不能写HAVING score > 60 -
HAVING中所有字段，要么来自GROUP BY列，要么是聚合结果
容易被忽略的隐式陷阱
即使语法通过，结果也可能错得离谱，尤其当字段存在隐式类型转换或 NULL 时：
-
GROUP BY user_id和GROUP BY CAST(user_id AS CHAR)在某些场景下分组结果不同，特别是字段类型为INT却存了字符串 ID - 所有
NULL被视为同一组，但WHERE col IS NOT NULL会提前过滤，导致分组统计口径不一致 - 字符串字段带空格或大小写混用（如
'admin '和'ADMIN'）会被分到不同组，查分布时建议先TRIM(UPPER(col)) -
COUNT(*)、COUNT(col)、COUNT(1)行为不同，误用会导致统计偏差，比如COUNT(status)会跳过NULL状态
GROUP BY 的本质不是“去重”或“取第一行”，而是定义聚合单元。任何绕过语义清晰性的写法，短期省事，长期埋雷。
