MySQL 8.0+ 中 GROUP BY 不再隐式排序，必须显式使用 ORDER BY；ORDER BY 字段须在 GROUP BY 或聚合函数中，否则报错；索引覆盖可避免 filesort；复杂排序取 Top-N 推荐窗口函数。
MySQL 8.0+ 中 GROUP BY 不再隐式排序，ORDER BY 必须显式写出
MySQL 5.7 及以前版本中，GROUP BY 会默认按分组字段升序排序，很多旧代码依赖这个行为做展示或分页。但从 MySQL 8.0 开始，这个隐式排序被移除（SQL 标准要求），执行 SELECT ... GROUP BY x 后结果顺序不再保证。如果你发现分页错乱、前端列表顺序突变，大概率是这个原因。
显式加 ORDER BY 是唯一合规且安全的做法
想让分组后结果有序，必须写 ORDER BY。但要注意：不能只写 ORDER BY 字段而不写在 SELECT 列表中——除非该字段在 GROUP BY 中出现（MySQL 5.7 兼容模式下允许，8.0+ 严格模式下会报错 Expression #1 of ORDER BY clause is not in GROUP BY clause）。
常见写法示例：
SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id ORDER BY user_id; -- ✅ 安全：user_id 在 GROUP BY 中
错误写法：
SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id ORDER BY created_at; -- ❌ 报错：created_at 既不在 GROUP BY 也不在聚合函数中
性能影响主要来自排序方式和索引是否覆盖
加 ORDER BY 本身不必然慢，关键看是否能走索引排序（Using filesort 要警惕）。满足以下任一条件时，MySQL 可跳过额外排序步骤：
-
ORDER BY字段完全匹配GROUP BY字段（顺序、方向一致），且该字段有索引 - 存在联合索引覆盖
GROUP BY + ORDER BY字段，例如(user_id, status)，而语句是GROUP BY user_id ORDER BY user_id - 使用
ORDER BY NULL显式禁止排序（仅当你真不需要顺序时）
避免踩坑：
- 不要用
ORDER BY RAND()配合GROUP BY—— 触发全表扫描+临时表+排序，极慢 - 如果分组后只取前 N 条，把
LIMIT放在ORDER BY后面，否则 MySQL 可能先排序全部结果再截断 - 检查
EXPLAIN输出中的Extra列：出现Using temporary; Using filesort就说明没走索引排序
复杂场景下考虑用窗口函数替代 GROUP BY + ORDER BY
当既要分组聚合，又要按某字段排序取 Top-N（比如“每个用户最新一笔订单”），硬套 GROUP BY + ORDER BY + LIMIT 很难写对，还容易误用。此时更清晰高效的方式是用窗口函数：
SELECT user_id, order_id, created_at
FROM (
SELECT user_id, order_id, created_at,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
FROM orders
) t
WHERE rn = 1;这种写法逻辑明确、可读性强，且在有合适索引（如 (user_id, created_at)）时性能通常优于老式自关联或子查询方案。注意：窗口函数要求 MySQL 8.0+，且不能用于所有聚合场景（比如需要 SUM + 排序并存时仍需组合使用）。
真正容易被忽略的是：即使加了 ORDER BY，如果没建对索引，或者用了非确定性表达式（如 ORDER BY COUNT(*)），MySQL 仍可能放弃索引排序，回退到文件排序。验证永远比假设可靠——查 EXPLAIN，别信感觉。
