MySQL 8.0 取消 GROUP BY 隐式排序是主动对标 SQL 标准，非 bug 或性能退化；升级后必须显式添加符合规则的 ORDER BY，否则分页错乱、列表跳变、导出顺序不固定，且 ORDER BY 字段须在 GROUP BY 中或被聚合函数包裹。
MySQL 8.0 明确取消 GROUP BY 隐式排序是 SQL 标准对齐行为
这不是 bug，也不是性能退化，而是 MySQL 主动放弃一个历史“便利”，向 ANSI/ISO SQL 标准靠拢。5.7 及更早版本中 GROUP BY x 看似按 x 升序返回，本质是优化器碰巧走索引扫描或顺带做了排序——官方文档早在 5.7 就已标注该行为为 “deprecated”（不推荐依赖）。8.0 直接移除这个副作用，让结果顺序真正“不确定”，倒逼开发者写出语义明确、可预期的 SQL。
ORDER BY 缺失导致分页错乱、前端列表跳变
很多老系统代码没写 ORDER BY，却靠 GROUP BY 的隐式排序做分页或渲染列表。升级到 8.0 后，同一查询可能每次返回顺序不同，造成：
- 分页时某条记录在第 1 页和第 2 页重复出现
- 前端表格刷新后行顺序随机打乱，用户以为数据错乱
- 导出 Excel 时分类汇总顺序不固定，审计难复现
这类问题不会报错，但线上暴露后极难定位。必须逐个检查所有含 GROUP BY 的 SELECT，补上显式的 ORDER BY，且字段必须出现在 GROUP BY 列表或聚合函数中。
ORDER BY 字段不在 GROUP BY 中就报错
8.0 严格模式下，ORDER BY 字段若既未出现在 GROUP BY 子句，又未被聚合函数包裹，会直接报错：
Expression #1 of ORDER BY clause is not in GROUP BY clause
例如以下写法在 8.0 中非法：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY created_at;
因为 created_at 是每组多值，数据库无法确定该取哪一条。可行解法包括：
- 改用聚合：
ORDER BY MAX(created_at) - 改用窗口函数取 Top-N 场景（如“每个用户最新订单”）
- 确认业务是否真需要该字段排序——有时只是误加
索引能否避免 filesort 成为性能关键点
加了 ORDER BY 不等于慢，关键看是否触发 Using filesort。满足以下任一条件，MySQL 可直接利用索引有序性完成排序：
-
ORDER BY字段与GROUP BY字段完全一致（含顺序、方向），且该字段有索引 - 存在联合索引覆盖
GROUP BY + ORDER BY字段，例如(category, product_id)，而查询是GROUP BY category ORDER BY category - 使用
ORDER BY NULL显式声明无需排序（仅限你确定顺序无关紧要时）
执行前务必 EXPLAIN 检查 Extra 列：若出现 Using temporary; Using filesort，说明索引未生效，需调整索引或重写查询逻辑。
