order by执行有明确逻辑和性能代价：默认asc可省略，desc需显式声明；多列排序严格从左到右逐层生效；null在asc时排最前、desc时排最后，8.0+支持nulls last；性能关键在索引是否匹配排序字段及顺序。
SQL的ORDER BY不是简单“排个序”就完事，它背后有明确的执行逻辑和性能代价。理解排序规则怎么起作用、为什么有时慢、哪些写法容易踩坑，才能写出既正确又高效的查询。
排序方向与默认行为
升序（ASC）是默认行为，可省略；降序必须显式写DESC。比如：
-
ORDER BY price等价于ORDER BY price ASC，从小到大排 -
ORDER BY created_at DESC按时间倒序，最新记录在前 - 多列混合时，每列可独立指定方向：
ORDER BY dept ASC, salary DESC
多字段排序的优先级逻辑
MySQL严格按书写顺序从左到右逐层生效：
- 先按第一列排序，值不同时直接确定先后
- 只有第一列值相等，才启用第二列排序
- 第三列及后续仅在前两列都相同时才参与比较
- 不建议用列序号（如
ORDER BY 2）——SELECT字段一改，排序就错位
NULL值的默认位置与调整方法
MySQL中NULL值在排序时有固定倾向：
- 升序（
ASC）：NULL排最前面 - 降序（
DESC）：NULL排最后面 - MySQL 8.0+ 支持显式控制：
ORDER BY salary ASC NULLS LAST - 低版本可用技巧：
ORDER BY ISNULL(salary), salary ASC把NULL当0排后面
排序性能的关键：索引是否命中
真正影响速度的不是ORDER BY本身，而是MySQL能否跳过排序步骤：
- “索引排序”：如果
ORDER BY字段有合适索引（且WHERE条件未破坏索引使用），MySQL直接按索引物理顺序读取，无额外开销 - “文件排序（filesort）”：没索引或索引不匹配时，MySQL要把结果装进内存或磁盘临时区再排序，数据量一大就明显变慢
- 优化重点：为高频排序字段建索引，例如
CREATE INDEX idx_logs_time ON logs(created_at) - 组合排序场景下，索引字段顺序要和ORDER BY一致，如
ORDER BY status ASC, updated_at DESC，对应索引应为(status, updated_at)
