ORDER BY 是唯一保证查询结果排序的方式；未指定时行顺序未定义，可能因索引、优化器或环境变化而改变，主键或历史有序均不构成保证，分页需配合唯一排序列。
不可靠，除非显式使用 ORDER BY 子句。
ORDER BY 是唯一保证排序的方式
SQL 标准明确规定：若查询中未指定 ORDER BY，数据库返回的行顺序是**未定义的**。即使某次执行看起来有序（比如按主键或插入顺序排列），也只是巧合——可能源于索引扫描、存储结构或优化器选择的执行计划，而非语义保证。不同版本、负载变化、统计信息更新甚至加个新索引，都可能导致顺序突变。
MyBatis3.2.3帮助文档 中文CHM版
下载
MyBatis 是支持普通 SQL 查询,存储过程和高级映射的优秀持久层框架。MyBatis 消除 了几乎所有的 JDBC 代码和参数的手工设置以及结果集的检索。MyBatis 使用简单的 XML 或注解用于配置和原始映射,将接口和 Java 的 POJOs(Plan Old Java Objects,普通的 Java 对象)映射成数据库中的记录。有需要的朋友可以下载看看
常见误解场景
- 主键/聚集索引存在 ≠ 自动排序：即使表有主键或按某列聚集，SELECT * 不带 ORDER BY 时，SQL Server、PostgreSQL、MySQL 等均不承诺返回顺序。
- 上次运行有序，这次也一定有序？：错误。并行查询、缓冲区状态、分页优化（如 LIMIT/OFFSET）都可能改变结果顺序。
- 应用层“默认”排序错觉：某些 ORM 或客户端工具可能对结果做隐式排序（如按字段名），但这不属于 SQL 层行为，不可依赖。
如何确保可预期的顺序
- 所有需要确定顺序的查询，必须写明 ORDER BY 列名（支持多列、ASC/DESC、表达式、别名）。
- 涉及分页（如 LIMIT + OFFSET）时，ORDER BY 必须包含唯一性组合（例如主键），否则相同排序值的行可能在不同页重复或遗漏。
- 避免依赖数据库特定行为，如 MySQL 的 GROUP BY 隐式排序（8.0+ 已默认禁用）或 PostgreSQL 的 “toplevel ORDER BY 优化”。
特殊情况：窗口函数与排序
像 ROW_NUMBER() OVER (ORDER BY ...) 这类窗口函数内部的 ORDER BY 只影响该函数计算逻辑，不决定最终结果集顺序。若需整体有序，仍需在外层再加 ORDER BY。
