不写order by时数据库返回顺序无保证，因sql标准允许任意物理顺序；order by字段重复时仍需追加唯一键（如主键id）确保稳定排序，否则分页等场景易出错。
不写 ORDER BY，数据库根本不管顺序
SQL 标准明确允许数据库对未排序的结果集以任意物理顺序返回——这不是 bug，是设计如此。MySQL InnoDB 表“看起来按主键排”，PostgreSQL “看起来按插入顺序排”，都只是执行计划偶然导致的表象，不是保证。哪怕同一张表、同一条 SQL、同一时刻执行两次，只要查询计划稍有变化（比如统计信息更新、缓冲区状态不同、并行线程调度差异），顺序就可能翻转。
常见错误现象：SELECT * FROM users WHERE status = 'active' 在本地开发环境每次结果一样，上线后突然乱序；或者加了个新索引，原本“稳定”的顺序就崩了。
- MyISAM 表可能按数据文件物理顺序返回，但删过记录后就不可靠
- InnoDB 表通常走聚簇索引扫描，看似按主键排，但优化器可能选二级索引 + 回表，顺序立刻变
- PostgreSQL 的 Bitmap Heap Scan 或并行 Seq Scan 会让顺序彻底随机
ORDER BY 字段重复时，顺序仍可能漂移
只写 ORDER BY status 是不够的。当多行 status = 'pending' 时，数据库对这些行的相对位置不做任何承诺。它们可能这次排在前面，下次被其他并发写入“挤”到中间，甚至因索引重建而重排。
真正起作用的是“排序键组合唯一”。例如 ORDER BY status, id 中，id 是主键，能确保每行在排序中获得唯一位置。
- 别用
created_at当次要排序字段：高并发下时间戳完全可能重复 - 复合主键必须全列写出：
ORDER BY status, tenant_id, order_no，少一个就失去稳定性 -
ORDER BY status DESC, id和ORDER BY status DESC, id DESC效果不同：后者更符合分页连续性直觉
分页时 OFFSET + LIMIT 为什么特别危险
SELECT * FROM logs ORDER BY level LIMIT 10 OFFSET 20 看似合理，但一旦第 20–30 行里有两条 level = 'INFO' 记录，且它们的相对顺序不固定，第二次查询就可能漏掉其中一条，或重复出现——因为“第 21 条”这个位置本身在漂移。
根本问题不在 LIMIT，而在排序键不能锚定每一行。
- 修复方式不是加锁，而是让排序键足够唯一：
ORDER BY level, id - 生产环境建议直接弃用 OFFSET 分页，改用游标：
WHERE level >= 'INFO' AND id > 12345 ORDER BY level, id LIMIT 10 - 如果业务允许，把
id换成带时间戳的有序 ID（如 ULID、KSUID），还能兼顾可读性与排序稳定性
ORDER BY 里踩坑最狠的几件事
写错关键字、漏写方向、混用 NULL 处理逻辑，都会让排序“看起来对，实则错”。
-
ORDER BY created_at DSC→ 报错Unknown keyword 'DSC'，正确只能是DESC -
ORDER BY status, updated_at DESC→status实际是升序，不是“全部降序”，很多人误以为它也受 DESC 影响 - MySQL 升序时
NULL排最前，PostgreSQL 排最后，ORDER BY discount DESC在两边行为相反；要跨库一致，就得显式写NULLS LAST（PG/Oracle）或IFNULL(discount, -1)（MySQL） -
ORDER BY UPPER(name)无法走索引，应建函数索引或冗余字段，否则大数据量直接filesort
真实世界里，排序不稳定往往不是单点问题，而是多个隐含假设叠加的结果：默认顺序、时间戳唯一性、NULL 默认位置、索引覆盖范围……每个环节松动一点，最终结果就飘了。最省事的做法，不是猜数据库怎么想，而是每条带排序的 SQL 都明确写出能区分每一行的完整排序键。
