不加 ORDER BY 的查询结果顺序无保证，这是 SQL 标准行为；MySQL 5.7+ 默认不保留插入顺序，优化器依索引、统计信息等动态决定返回顺序，同一语句在不同环境或时间可能返回不同行序。
不加 ORDER BY 的查询，结果顺序没有保证——这不是 bug，是 SQL 标准行为。数据库优化器会根据索引、统计信息、执行计划甚至缓存状态动态决定返回顺序，同一语句在不同时间、不同负载下可能返回完全不同的行序。
ORDER BY 缺失导致的“随机”排序现象
常见错误场景：开发时本地 MySQL 返回按插入顺序排，上线后 PostgreSQL 或生产 MySQL 突然乱序；或加了索引后顺序又变了；或分页查第一页和第二页数据错位。
- MySQL 5.7+ 默认不保留插入顺序，即使没建索引，
SELECT *也不等于“按写入时间排” - PostgreSQL 和 SQL Server 更激进：只要走 BitmapScan 或并行查询，顺序就不可预测
- ORM 自动生成的 SQL（如 Django 的
.all()、Rails 的Model.all）若没显式调用.order()，底层就是裸SELECT
ORDER BY 中 ASC/DESC 写错或漏写
DESC 是唯一合法关键字，DSC、DESCENDING、DOWN 都报错；而 ASC 虽可省略，但漏写 DESC 会导致“以为降序，实为升序”，数据看起来“全反了”。
- 错误写法：
ORDER BY created_at DSC→ 报错Unknown keyword 'DSC' - 隐蔽错误：
ORDER BY status, updated_at DESC→status是升序，但很多人误以为它也受DESC影响 - 安全写法：
ORDER BY status ASC, updated_at DESC，每个方向都显式声明
多字段排序优先级与 NULL 处理陷阱
排序字段越靠左，优先级越高；NULL 的位置因数据库而异——MySQL 升序时 NULL 在最前，PostgreSQL 在最后，这直接导致分页或前端列表渲染错乱。
- 别依赖默认
NULL行为：ORDER BY discount DESC在 MySQL 中把无折扣商品顶到最前，在 PostgreSQL 中压到底部 - 显式控制：
ORDER BY discount DESC NULLS LAST（PostgreSQL / Oracle），MySQL 可用ORDER BY IFNULL(discount, -1) DESC - 避免用列位置排序：
ORDER BY 2不仅难读，一旦SELECT列顺序调整就崩，多数 DBA 规范禁用
性能与索引的关键提醒
ORDER BY 字段没索引，大数据量时会触发 filesort，查询变慢且内存占用飙升；但用表达式排序（如 ORDER BY UPPER(name)）会让索引失效。
- 建索引优先覆盖排序字段：
CREATE INDEX idx_status_updated ON orders(status, updated_at DESC); - 避免在
ORDER BY里计算：ORDER BY price * quantity无法走索引，应提前算好存为虚拟列或冗余字段 - 注意 COLLATE：字符串排序混乱常因字符集不一致，比如
utf8mb4_0900_as_cs和utf8mb4_unicode_ci对大小写/重音处理不同
真正要命的不是“忘了加 ORDER BY”，而是加了但没验证它在所有目标数据库上的实际行为——尤其是 NULL 位置、大小写敏感性和索引是否真生效。
