MySQL 5.7及以前GROUP BY隐式排序是优化器副作用，非标准行为；8.0起移除该机制，结果顺序不再保证，必须显式使用ORDER BY才能确保排序。
MySQL 5.7 以前的 GROUP BY 看似“自动排序”，其实只是优化器顺带干的活；8.0 起它彻底不干了——结果顺序不再保证，除非你写 ORDER BY。
MySQL 5.7 及更早版本的“隐式排序”是怎么来的
这不是标准行为，而是早期实现中的一种副作用：优化器常依赖 filesort 或按索引顺序扫描来完成分组，顺手就把结果排好序了。比如执行 SELECT category, COUNT(*) FROM products GROUP BY category;，返回结果大概率是按 category 升序排列的。
- 它不依赖 SQL 标准，也不受控制——加不加
ASC都一样默认升序 - 执行计划里常出现
Using temporary; Using filesort，说明排序真发生了 - 如果
GROUP BY字段上有索引，且走的是索引扫描（type: index），那排序更“稳”，但仍是实现细节，不是契约
MySQL 8.0 移除隐式排序的真实影响
升级到 8.0 后，同一句 GROUP BY 查询可能返回完全不同的行序——尤其当分组字段无索引、或数据量变大时。这不是 bug，是设计变更。
-
EXPLAIN中不再出现Using filesort（除非你显式写了ORDER BY） - 即使
GROUP BY字段有索引，也只用于加速分组，不保证输出顺序（除非该索引被用于覆盖扫描且引擎恰好按物理顺序读取） - 分页逻辑（如
LIMIT 10 OFFSET 20）在 5.7 和 8.0 下可能取到不同记录，极易引发前端列表错乱或重复/漏数据
如何安全适配 MySQL 8.0 的 GROUP BY 行为
不能靠“试出来”，必须显式声明排序意图。否则，哪怕测试环境看着有序，上线后也可能崩。
- 所有依赖分组后顺序的查询，必须补上
ORDER BY，例如：GROUP BY category ORDER BY category ASC - 避免用
ORDER BY NULL来“取消排序”——这在 8.0 已无必要，且容易掩盖真实需求 - 如果原逻辑依赖“按聚合值排序”，比如要取销量最高的前 3 个品类，得写成：
GROUP BY category ORDER BY SUM(sales) DESC LIMIT 3，而不是指望分组自动按销量排 - 注意
ONLY_FULL_GROUP_BY模式下，ORDER BY引用的字段必须出现在GROUP BY子句或为聚合表达式，否则报错：Expression #1 of ORDER BY clause is not in GROUP BY clause
最容易被忽略的一点：隐式排序消失后，原本靠“顺序稳定”实现的业务逻辑（比如用 MIN(id) 当代表 ID、或前端靠顺序做折叠展开）会直接失效——这些地方往往没写注释，也没测用例，上线后才暴露。别假设“没动 SQL 就没事”。
