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 很危险，用预编译参数又不支持字段名。稳妥方案是白名单校验字段名再拼，别图省事用字符串插值。