mysql 8.0 移除 group by 隐式排序是为对齐 sql 标准并支持并行聚合等优化，必须显式写 order by；否则顺序不可控，易致分页错乱、逻辑失效等问题。
MySQL 8.0 的 GROUP BY 不再默认排序，不是 bug，是主动移除的非标准行为——你不能指望它“碰巧有序”，必须显式写 ORDER BY。
为什么隐式排序被砍掉了？
因为它是历史包袱，不是 SQL 标准要求的行为。其他主流数据库（PostgreSQL、SQL Server、Oracle）从不保证 GROUP BY 结果顺序，MySQL 5.7 及以前的“自动排序”只是优化器实现时顺手干的活：要么走索引扫描，要么加 Using filesort。这种副作用让开发者误以为是契约，结果一升级就出问题。
MySQL 官方在 8.0 Release Note 明确说明：移除隐式排序是为了对齐 SQL 标准，并为后续优化（比如并行聚合、哈希分组）铺路。留着它，反而会阻碍执行计划选择。
没写 ORDER BY 会有什么实际影响？
- 同一句 SQL，在 5.7 和 8.0 下返回顺序可能完全不同——尤其当
GROUP BY字段无索引，或数据量变大后临时表换策略时 -
LIMIT+OFFSET分页逻辑崩掉：前端列表重复、漏数据、翻页错乱 - 依赖“第一个分组行即代表行”的逻辑失效，比如用
MIN(id)当主键 ID，但没显式排序，MIN(id)和分组顺序无关了 - 测试环境看着没问题，上线后流量一上来顺序就乱——因为小数据量常走索引，大数据量触发哈希分组，顺序彻底不可控
ORDER BY 怎么写才不报错也不慢？
MySQL 8.0+ 开启 ONLY_FULL_GROUP_BY（默认开启）后，ORDER BY 字段必须满足以下任一条件，否则直接报错：Expression #1 of ORDER BY clause is not in GROUP BY clause
- 字段出现在
GROUP BY子句中（如GROUP BY user_id ORDER BY user_id） - 字段是聚合函数结果（如
ORDER BY COUNT(*) DESC） - 字段在
SELECT列表中且函数依赖于GROUP BY字段（较复杂，不建议依赖）
性能关键点：
- 如果
ORDER BY字段和GROUP BY字段完全一致（含方向），且该字段有索引，MySQL 可跳过Using filesort - 联合索引如
(category, created_at)，查GROUP BY category ORDER BY category能复用索引 - 别写
ORDER BY RAND()配合GROUP BY——必然全表扫描 + 临时表 + 排序，极慢
复杂排序需求（比如每个分组取最新一条）别硬套 GROUP BY
想按聚合值排序再取 Top-N（如“销量最高的前 3 个品类”），或者“每个用户最新一笔订单”，硬塞 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;
这类场景下，GROUP BY 不是万能解法，强行用反而掩盖真实语义。
最容易被忽略的，是那些没写注释、没覆盖测试、靠“看起来有序”跑了几年的旧逻辑——它们不会报错，但会在 8.0 上静默错乱。别等线上报警才查。
