ORDER BY 单列排序时ASC/DESC影响NULL处理、索引使用及跨库兼容性；多列排序按字典序逐列比较，方向须显式指定；表达式可直接排序，别名排序不具通用性；全表ORDER BY需配合匹配索引避免filesort。
ORDER BY 单列排序时 ASC 和 DESC 的实际影响
默认升序（ASC）常被忽略，但显式写出更安全——尤其当字段含 NULL 时，不同数据库对 NULL 的排序位置处理不一致（MySQL 默认 NULL 在前，PostgreSQL 默认在后）。如果业务逻辑依赖 NULL 排在末尾，必须加 DESC 或用 IS NULL 手动控制。
常见错误是写成 ORDER BY status ASC NULLS LAST——这在 MySQL 中直接报错，因为 NULLS LAST 是 PostgreSQL/Oracle 语法，MySQL 不支持。实操建议：
- MySQL 用户：用
ORDER BY IF(ISNULL(status), 1, 0), status把NULL推到最后 - PostgreSQL 用户：可放心用
ORDER BY status NULLS LAST - 排序字段带索引时，
ASC/DESC会影响是否能走索引扫描（如索引是(created_at ASC)，查ORDER BY created_at DESC在旧版本 MySQL 可能无法利用）
多列 ORDER BY 的优先级和方向独立性
多列排序不是“先按 A 排再按 B 排”的线性理解，而是按字典序逐列比较：只有当前面所有列值相等时，才看下一列。比如 ORDER BY category ASC, price DESC，会先分组同 category，每组内再按 price 降序。
容易踩的坑是认为方向可以省略或继承——实际上每列方向必须单独指定，默认全是 ASC。下面写法是错的：
ORDER BY category, price DESC -- ❌ category 实际是 ASC，但没写清楚，易误读
正确写法应明确每列方向：
-
ORDER BY category ASC, price DESC（推荐，意图清晰） - 混合方向在分页场景下要特别小心：若上一页最后一条是
('books', 29.99)，下一页用WHERE (category, price) > ('books', 29.99)仅在两列同为ASC时可靠；含DESC列需反转比较逻辑 - SQL Server 对多列排序方向敏感，若索引是
(a ASC, b DESC)，而查询写ORDER BY a ASC, b ASC就无法利用该索引
ORDER BY 中使用表达式或别名的兼容性差异
想按计算结果排序（比如按邮箱域名倒序），直接写 ORDER BY SUBSTRING_INDEX(email, '@', -1) DESC 大部分数据库都支持。但用列别名（如 SELECT email AS domain FROM users ORDER BY domain）就危险了：
- MySQL 5.7+ 和 PostgreSQL 支持，但标准 SQL 规定
ORDER BY不能引用SELECT中的别名（因逻辑执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY） - SQLite 允许，SQL Server 不允许（除非用子查询或 CTE 包一层）
- 最稳妥做法：重复表达式，或用子查询封装，避免跨库迁移时出错
ORDER BY 在分页和性能上的隐含成本
没有 WHERE 条件的 ORDER BY（比如全表查最新 10 条：SELECT * FROM logs ORDER BY id DESC LIMIT 10）看似简单，但若表有千万行，MySQL 仍会先对全表排序再取前 10——除非 id 有索引。关键点：
-
ORDER BY字段必须有索引，且索引顺序与排序方向匹配，才能避免 filesort - 复合索引要注意顺序：要支持
ORDER BY a ASC, b DESC，索引应建为(a, b)（MySQL 8.0+ 支持降序索引，可建(a ASC, b DESC)） - 在
GROUP BY后接ORDER BY时，如果两者字段不一致，MySQL 可能强制临时表排序，即使有索引也无效
真正麻烦的是动态排序需求——比如前端传参决定按哪个字段排。这时候拼 SQL 很危险，用预编译参数又不支持字段名。稳妥方案是白名单校验字段名再拼，别图省事用字符串插值。
