mysql 5.7+报“is not in group by clause”错误是因only_full_group_by校验失败，非排序失效；须确保order by字段在group by中或为聚合结果（如max(created_at)），禁用模式仅掩盖问题。
ORDER BY 字段报 “is not in GROUP BY clause” 错误
这是 MySQL 5.7+ 默认开启 ONLY_FULL_GROUP_BY 后最常遇到的“排序无效”假象——实际根本没执行到排序，SQL 直接报错中断了。
错误本质是语义校验失败，不是排序被忽略。比如写 SELECT dept_id, name FROM employees GROUP BY dept_id ORDER BY name，name 既不在 GROUP BY 列表里，也没被 MAX(name) 这类聚合包裹，数据库无法确定该取哪条 name 来排序。
- 别关
sql_mode去绕过——线上环境换版本或迁移 PostgreSQL 就立刻崩 - 真要按
name排序？要么加进分组：GROUP BY dept_id, name；要么用聚合兜底：ORDER BY MAX(name)（注意语义是否合理） - 更常见也更合理的做法是按时间维度排序，例如
ORDER BY MAX(created_at) DESC，语义明确且跨版本兼容
子查询中先 ORDER BY 再 GROUP BY 却不返回最新一条
这种写法在 MySQL 5.6 可能“碰巧”有效，但在 5.7+ 中大概率失效：SELECT * FROM (SELECT * FROM orders ORDER BY created_at DESC) t GROUP BY customer_id。优化器启用 derived_merge 后，会直接丢弃子查询里的 ORDER BY，导致返回的是每组任意一条（通常是物理存储顺序第一条）。
- 加超大
LIMIT是最轻量的修复：ORDER BY created_at DESC LIMIT 999999999，强制优化器放弃合并 - 用
HAVING 1=1干扰优化器判断也有效，但属于“黑盒技巧”，可读性差 - 真正健壮的做法是换思路：用关联子查询（如
WHERE id IN (SELECT MAX(id) ...)）或 MySQL 8.0+ 的窗口函数ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY created_at DESC)
ORDER BY 聚合别名（如 avg_salary）不生效
很多人写 SELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY dept_id ORDER BY avg_salary DESC，结果排序乱序甚至报错。这不是 bug，而是 SQL 执行顺序决定的：GROUP BY → 聚合 → SELECT → ORDER BY，部分 MySQL 版本在复杂嵌套中无法在 ORDER BY 阶段识别别名。
- 最稳方案：在
ORDER BY中直接复写表达式，比如ORDER BY AVG(salary) DESC - 别用位置序号（如
ORDER BY 2）——加个字段就全错，维护成本高 - 如果必须用别名，包一层外层查询：
SELECT * FROM (SELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY dept_id) t ORDER BY avg_salary DESC
JOIN + GROUP BY + ORDER BY 组合下排序结果不稳定
LEFT JOIN 后按右表字段（如 orders.status）排序，但右表没索引、或连接条件未有效过滤，优化器可能放弃索引排序，退化成 Using filesort，结果看似随机。
- 用
EXPLAIN看key和Extra列：出现Using filesort就说明没走索引 -
ORDER BY字段尽量落在驱动表（FROM后第一张表）上，并确保有索引 - 对高频组合场景（如按
dept_id分组 + 按MAX(created_at)排序），建复合索引更可靠：INDEX idx_dept_created (dept_id, created_at)
核心就一点：SQL 中没有“隐式最新”这回事。所有排序目标必须显式声明为聚合值、子查询结果或窗口函数输出——模糊的字段引用，永远得不到稳定结果。
