不加ORDER BY的聚合结果顺序不可预测，完全依赖执行计划、数据分布等底层因素；SQL标准明确规定，仅ORDER BY能保证输出顺序，GROUP BY不提供排序保障。
不加 ORDER BY 的聚合结果，根本就没有“排序”可言——它只是数据库随手吐出来的一堆行，顺序由执行计划、缓冲区、线程调度甚至内存碎片决定。
聚合查询不写 ORDER BY 就没顺序保障
很多人以为 GROUP BY 后的结果天然按分组字段排好序了，其实不是。SQL 标准里明确说：除非显式写 ORDER BY，否则结果集顺序不可预测。MySQL 5.7、PostgreSQL、SQL Server 全都遵守这点——哪怕你刚看到一次“碰巧有序”，下次就可能乱。
- 执行计划变更（比如索引失效、统计信息过期）会直接让输出顺序变样
- 并行查询时，多个线程归并结果的时机不同，顺序就不同
- 同一语句在开发机和生产库跑，因数据量/配置差异，顺序也可能不一致
GROUP BY 和 ORDER BY 是两回事
GROUP BY 只负责把行分组，不控制最终结果怎么列出来；ORDER BY 才是唯一能锁定输出顺序的子句。两者可以共存，但不能互相替代。
- 错误写法：
SELECT region, COUNT(*) FROM sales GROUP BY region→ region 顺序完全不确定 - 正确写法：
SELECT region, COUNT(*) FROM sales GROUP BY region ORDER BY region - 如果 region 有 NULL，还想让它排最后？MySQL 5.7 得这么写：
ORDER BY IF(region IS NULL, 1, 0), region
聚合后排序字段含 NULL 或类型混杂，容易踩坑
聚合函数（如 AVG()、SUM()）自动忽略 NULL，但排序时 NULL 本身参与比较，而不同数据库对 NULL 的默认位置处理不一：
- PostgreSQL 默认
NULLS FIRST，ORDER BY col会让 NULL 排最前 - Oracle 默认
NULLS LAST，同一条语句在两边跑，顺序可能相反 - 字符串字段存了数字（如
'1','10','2'），直接ORDER BY会按字典序排成1, 10, 2，得用CAST(col AS UNSIGNED)转整数再排
聚合 + 多字段排序时，次要字段必须能破歧义
当主排序字段（比如 AVG(salary)）值相同时，仅靠它无法稳定顺序。这时候必须加一个唯一或高区分度字段作兜底：
- 推荐用主键：
ORDER BY AVG(salary) DESC, dept_id - 避免用无索引字段，否则排序性能暴跌
- 如果
dept_id也不唯一，就继续加：ORDER BY AVG(salary) DESC, dept_id, created_at
真正容易被忽略的是：即使你只在开发环境看到过一次“看起来有序”的聚合结果，也不能当作行为契约——只要没写 ORDER BY，它随时可能变。
