不加ORDER BY的查询结果顺序永远不可预测，这是SQL标准强制规定；所谓“看起来有序”只是执行路径、索引或缓存等偶然因素导致的错觉，实际顺序会随数据量、版本、执行计划等变化而改变。
不加 ORDER BY 的查询，结果顺序永远不可预测——这不是数据库 bug，是 SQL 标准强制规定的行为。
为什么“看起来有序”其实是错觉
你本地查出来按 id 排、测试环境刚好按插入时间排，只是碰巧用了某个索引或执行路径。一旦表数据量变大、加了新索引、升级小版本、开启并行查询，甚至只是缓存被刷掉，顺序就可能全乱。
- MySQL 5.7+ 明确废弃了对主键或聚簇索引的隐式排序保证
- PostgreSQL 在 BitmapScan 或并行计划下，连物理页顺序都不保留
- SQL Server 的
TOP不带ORDER BY，拿的是当前执行时内存/磁盘页的任意前 N 行 - Oracle 分页（
OFFSET ... FETCH）没ORDER BY时，同一语句两次执行可能返回重复或漏掉的行
ORDER BY 字段组合必须能唯一确定每行位置
只写 ORDER BY status 是危险的：当多条记录 status = 'active' 时，它们之间的相对顺序无定义。数据库每次可能随机排列，导致分页跳变、前端列表刷新后顺序突变。
- 安全做法是补上参与业务逻辑的唯一标识，比如
ORDER BY status ASC, created_at DESC, id ASC - 如果是一对多关联（如订单 + 订单项），要稳定排序就得覆盖左表和右表的主键：
ORDER BY a.id, b.updated_at DESC, b.id - 别依赖
GROUP BY带来的“顺手排序”——它不保证顺序，且在 MySQL 8.0+ 中已彻底移除该隐式行为
ASC/DESC 方向必须显式写出，别靠默认
ORDER BY status, updated_at DESC 实际等价于 status ASC, updated_at DESC。很多人误以为 DESC 会“传染”到前面字段，结果发现 status 总是升序归类，打乱了预期的全局时间倒序。
- 所有方向都显式声明：
ORDER BY status ASC, updated_at DESC, name ASC -
NULL值位置因库而异：PostgreSQL 默认NULLS LAST，MySQL 则NULL在最前；要跨库一致，用COALESCE(updated_at, '1970-01-01') DESC或IFNULL(updated_at, '1970-01-01') DESC - 禁止用列位置排序（如
ORDER BY 2, 3）——SELECT 字段一调整，查询就失效，且多数团队规范直接禁止
真正容易被忽略的点是：**即使你加了 ORDER BY，只要排序字段组合不能唯一区分每一行，数据库仍有自由决定“相同值组内”的顺序——这个自由度在分页、导出、前端渲染中会直接暴露为抖动、重复或丢失。**
