在关系型数据库中执行一条没有排序子句的查询时，返回行的顺序常常让人误以为固定不变。实际上，SQL 标准明确规定，如果语句中没有 order by，结果集的顺序是不确定的。数据库引擎会根据成本最优原则选择扫描路径，这可能涉及索引命中、分区裁剪或并行归并，因此同一条 SQL 在测试库和生产库、在不同统计信息下都可能给出不同排列。
为什么默认顺序不可靠
表在逻辑上是一个无序的行集合。数据库不保证按插入顺序或主键顺序返回，除非你明确要求。下面几个因素都会改变输出顺序：
- 优化器选择了不同的索引进行覆盖扫描
- 执行了并行查询，各线程结果合并的先后顺序不固定
- 表经过重建、分区交换或缓存淘汰后物理存储变化
一个常见误区
有人发现加上主键后似乎总是按 id 升序，就认为 select * from user 永远按 id 排。这只是在特定执行计划下的巧合，一旦优化器改走全表扫描或其他索引，顺序就可能变化。
如何保证可靠的查询顺序
唯一标准做法是在查询中写明确的 order by。哪怕只需要任意稳定顺序，也应指定一列或表达式。
-- 按注册时间倒序，时间相同再按 id 保证稳定 select id, name, create_time from user order by create_time desc, id asc;
分页场景更要注意
在 limit 分页中，如果 order by 不唯一，可能出现同一行在前后页重复或丢失。应使用具有唯一性的排序列组合。
select id, title from article order by publish_date desc, id asc limit 10 offset 20;
不同数据库的小差异
多数主流数据库都遵循上述规则，但细节略有不同：
| 数据库 | 无 order by 时的表现 |
|---|---|
| MySQL | 可能按主键或存储顺序，但不保证 |
| PostgreSQL | 通常按堆扫描顺序，随计划改变 |
| Oracle | 依赖执行计划，顺序不稳定 |
总结建议
不要在任何业务代码中依赖没有 order by 的查询结果顺序。展示列表、导出文件、批量处理都应以显式排序为准。若调用类似 input() 的函数读取结果，也请先确认上游 SQL 已排序，否则逻辑可能在某些环境突然错乱。