SQL语句中GROUP BY与ORDER BY同时使用必须注意的几个关键点

在SQL中，GROUP BY 和 ORDER BY 同时使用时存在陷阱，尤其是当你期望获取每组最新或最高记录时，很容易出错。许多开发者误以为先排序再分组就能得到正确结果，但实际上查询结果往往与预期不符。

简而言之，GROUP BY 和 ORDER BY 在执行顺序上存在一个隐蔽的差异，一旦理解错误，整个逻辑就会混乱。

ORDER BY 字段必须在 GROUP BY 列表里或套聚合函数

首先来看一个常见的语法陷阱。在 MySQL 5.7 及以上版本中，默认开启了 ONLY_FULL_GROUP_BY 模式。只要 ORDER BY 后面的字段既未出现在 GROUP BY 子句中，也没有被 MAX()、COUNT() 等聚合函数包裹，数据库就会直接报错：Expression #1 of ORDER BY clause is not in GROUP BY clause。

例如，以下错误写法：

• SELECT examId, score FROM ko_monthly_exam_history GROUP BY examId ORDER BY score DESC —— 这里 score 既未分组也未聚合，无法通过。

如何修正？有两种常见思路：

• 使用聚合函数兜底：SELECT examId, MAX(score) AS score FROM ko_monthly_exam_history GROUP BY examId ORDER BY score DESC
• 或者将 score 也加入分组列表：SELECT examId, score FROM ko_monthly_exam_history GROUP BY examId, score ORDER BY score DESC —— 但此时语义已变，不再是“每组一条”，而是变成了去重组合。

GROUP BY 后的 ORDER BY 不会帮你挑组内最大/最新记录

即便语法通过了，逻辑上还有一个更隐蔽的陷阱。很多人误以为 GROUP BY 之后再加 ORDER BY，就能取出每组中最大的那条记录。然而，这只是错觉。

实际执行情况是：GROUP BY 先执行，它只保留每组的第一行——这个第一行取决于物理顺序或引擎的默认行为，与你想要的“最大/最新”毫无关系。随后 ORDER BY 再对这“一行”的字段进行排序，组内其他数据它根本看不到。

例如：SELECT id, examId, score FROM t GROUP BY examId ORDER BY score DESC，返回的 id 很可能对应的是该组中最低分的那条记录，而非最高分。

根本原因在于执行顺序：FROM → WHERE → GROUP BY → SELECT → ORDER BY。ORDER BY 执行时，组内的全量数据早已被 GROUP BY 压缩掉了。

还有一个常见的错误做法：有人试图用“子查询先 ORDER BY 再 GROUP BY”来绕过这个问题。但 MySQL 5.7+ 的优化器会直接丢弃子查询里的 ORDER BY，除非你加上 LIMIT 999999999 这种强制保留的写法——但这种方式既不优雅也不推荐。

真正要取每组最新/最高记录，得用窗口函数或关联子查询

如果你确实需要按 examId 分组，并从每组中取出 score 最高、time 最新的那条完整记录，那么必须跳出 GROUP BY 的限制。以下是两个靠谱的方案：

• MySQL 8.0 及以上版本，推荐使用窗口函数：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY examId ORDER BY score DESC, time DESC) AS rn FROM ko_monthly_exam_history) t WHERE t.rn = 1
• 如果是老版本，用关联子查询也能搞定：SELECT t1.* FROM ko_monthly_exam_history t1 WHERE t1.id = (SELECT id FROM ko_monthly_exam_history t2 WHERE t2.examId = t1.examId ORDER BY score DESC, time DESC LIMIT 1)

使用子查询时还有一个容易踩的坑：SELECT * FROM (SELECT * FROM t ORDER BY score DESC LIMIT 1000) s GROUP BY examId 这种写法，如果某个 examId 的最高分没有进入前 1000 名，它就会被遗漏。LIMIT 必须放到最外层才安全。

ORDER BY 字段没索引会导致排序失效

最后补充一个性能相关的要点。即使语法合法、逻辑正确，如果 ORDER BY 字段没有索引，MySQL 就会走 Using filesort。结果顺序看起来像随机，性能也惨不忍睹。

检查方法很简单：使用 EXPLAIN 查看 Extra 列，如果出现 Using filesort，说明没有走索引排序。

几个实用建议：

• ORDER BY 字段尽量落在驱动表上——也就是 FROM 后面的第一张表。
• 复合索引更稳妥。例如，你经常按 examId 分组，再按 MAX(time) 排序，那么建一个 INDEX idx_exam_time (examId, time) 会非常高效。
• 避免使用 ORDER BY 2 这种位置引用——字段增减后，排序可能完全乱掉。

最容易被忽略的一点是：你以为 GROUP BY + ORDER BY 能取到每组最优记录，其实它只负责对组进行排序。真正筛选组内数据，还得靠窗口函数、子查询，或者在业务层做二次处理。别让 ONLY_FULL_GROUP_BY 报错把你骗过去——报错只是表象，逻辑错才是根因。