GROUP BY 不保证顺序，必须显式写 ORDER BY；ORDER BY 字段须为 SELECT 输出列或聚合表达式，且最好有索引；分组内取最新记录需用窗口函数而非 GROUP BY + ORDER BY。

GROUP BY 本身不保证任何顺序。

所谓“排序不稳定”不是 bug，而是你没写 ORDER BY，或者写了但字段不合法、不被识别、没走索引。

GROUP BY 后必须显式写 ORDER BY

不少人会想当然地觉得，GROUP BY 做完分组后，结果也会顺手按分组键排好序。

比如写了 GROUP BY category，就以为输出一定会按 category 的升序来。

但事实并非如此。结果集的顺序本身是完全未定义的。

这次看起来可能是 A-B-C，下次就可能变成 C-A-B。

特别是当数据量发生变化、加了 WHERE 条件，或者只是切换了 MySQL 的小版本时，这个问题往往就会暴露出来。

• 正确姿势：所有分组查询，只要对输出顺序有要求，ORDER BY 必须显式写出，且放在 GROUP BY 之后
• 错误写法：SELECT category, COUNT(*) FROM t GROUP BY category ORDER BY id —— id 没出现在 SELECT 或 GROUP BY 中，多数数据库直接报错
• 不推荐：ORDER BY 1 虽然部分 MySQL 版本能跑，但 SELECT 列一改，序号就错，维护成本高

ORDER BY 字段必须是 SELECT 输出列或聚合表达式

MySQL 执行顺序是 GROUP BY → SELECT → ORDER BY。

所以 ORDER BY 只能引用最终 SELECT 出来的字段，或其别名。

不能引用原始表中未选中的列。

• 正确：SELECT dept_id, A VG(salary) AS a vg_salary FROM employees GROUP BY dept_id ORDER BY A VG(salary) DESC
• 风险：ORDER BY a vg_salary DESC —— 在某些嵌套查询或旧版本中，别名解析失败，静默退化为无序
• 更稳写法：包一层子查询，SELECT * FROM (SELECT dept_id, A VG(salary) AS a vg_salary FROM employees GROUP BY dept_id) t ORDER BY a vg_salary DESC
• 错误：ORDER BY created_at —— 如果 created_at 没进 SELECT，也没用 MAX(created_at) 等聚合，就非法

ORDER BY 字段没索引？大概率触发 Using filesort

即使语法全对，ORDER BY 字段没索引，或者索引顺序不匹配，MySQL 就不得不做文件排序，也就是 Using filesort。

结果看似有序，但性能差，并发高时顺序还可能波动。

• 用 EXPLAIN 看执行计划：Extra 列出现 Using filesort 就是信号
• 联合索引要覆盖完整访问链：比如常查 GROUP BY dept_id, region ORDER BY COUNT(*) DESC，建索引 (dept_id, region) 可加速分组，但排序仍需额外开销；若改成 ORDER BY MAX(updated_at) DESC，索引应为 (dept_id, region, updated_at)
• 避免在 ORDER BY 里用函数或表达式，如 ORDER BY UPPER(name)，索引失效
• ORDER BY NULL 可强制跳过隐式排序，仅适用于你真不需要顺序的场景，比如只取 COUNT(*) 总数

分组内还要控制顺序？别硬套 GROUP BY

如果需求是“每个分组里取最新一条记录”，比如每类商品取 MAX(created_at) 对应的 name 和 price，GROUP BY + ORDER BY 无法解决。

它只排最终结果行的顺序，不决定每组内部哪一行被选中。

• 典型陷阱：SELECT category, name, MAX(created_at) FROM products GROUP BY category —— name 值随机，和 MAX(created_at) 不一定对应
• 正确解法：用窗口函数，ROW_NUMBER() OVER (PARTITION BY category ORDER BY created_at DESC) 标序号，外层 WHERE rn = 1
• MySQL 8.0+ 支持，旧版可用相关子查询，但性能差、写法冗长
• GROUP_CONCAT(name ORDER BY updated_at DESC) 是 MySQL 特有补救方案，适合拼字符串，不适合取单值

容易被忽略的问题

ORDER BY 字段存在大量 NULL，或类型混杂时，排序行为可能跨环境不一致。

比如 varchar 里混数字字符串，连 ORDER BY ... ASC 都可能出人意料。

先清洗数据，再分组排序，比调参数靠谱得多。

《夸克》非常好用的免费AI浏览器

下载APP查看