ORDER BY 是MySQL中唯一合法且被所有版本支持的排序语法，必须位于SELECT语句末尾（LIMIT前），支持列名、别名、表达式等，但不推荐用数字位置；默认升序，多字段排序严格从左到右；执行顺序为WHERE→GROUP BY→HAVING→ORDER BY→LIMIT；性能依赖索引匹配，无索引时大数据量易变慢。
ORDER BY 是排序的唯一标准写法
MySQL 中对查询结果排序，ORDER BY 是唯一合法且被所有版本支持的语法。它不是可选修饰，而是独立子句，必须出现在 SELECT 语句末尾（LIMIT 之前），不能省略关键词，也不能用其他方式替代。
- 不写
ASC或DESC时，默认按升序（ASC）排列，但显式写出更安全、可读性更强 -
ORDER BY后可跟列名、别名、表达式、甚至数字位置（如ORDER BY 2表示按 SELECT 第二个字段排序），但**不推荐用数字位置**——一旦 SELECT 列顺序调整，排序逻辑会悄无声息错乱 - 若排序字段含
NULL值，MySQL 默认把NULL当作最小值处理（即ASC时排最前，DESC时排最后），这点在统计类查询中容易引发误判
多字段排序：优先级严格从左到右
当需要“先按薪资降序，薪资相同时再按入职时间升序”，必须写成 ORDER BY salary DESC, entrydate ASC。这不是并列关系，而是嵌套判定逻辑：只有左侧字段值完全相等的行，才进入右侧字段的比较。
- 常见错误是以为
ORDER BY salary DESC, age DESC能“同时降序”，其实它等价于“主序降、次序也降”，和单字段无本质区别 - 如果写成
ORDER BY salary DESC, age（省略第二个ASC），语义完全正确，但建议统一显式标注，避免团队协作时理解偏差 - 性能上，多字段排序能否走索引，取决于索引定义顺序是否匹配
ORDER BY字段顺序及方向——例如有索引(salary, entrydate)，那么ORDER BY salary DESC, entrydate ASC就无法充分利用该索引（方向不一致）
带 WHERE 和 LIMIT 的排序，顺序不能乱
真实业务中，排序几乎总和过滤、分页一起出现。务必记住执行顺序：WHERE → GROUP BY → HAVING → ORDER BY → LIMIT。这意味着：
-
WHERE先筛出行，ORDER BY才对这些结果排序，LIMIT最后截取——所以“查最新5条订单”必须写成SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 5，而不是把LIMIT放前面 - 如果漏掉
WHERE条件直接ORDER BY ... LIMIT，可能返回大量无关数据后再排序截断，白白消耗 I/O 和 CPU - 某些 ORM（如早期 Django ORM）生成的 SQL 可能隐式调整子句顺序，遇到异常排序结果时，第一反应应是看实际执行的 SQL 是否符合这个顺序
别名、函数、表达式都能参与排序，但要注意兼容性
ORDER BY 支持对计算结果排序，比如按姓名长度排序：ORDER BY LENGTH(name) DESC；或按别名排序：SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users ORDER BY full_name。
- MySQL 8.0+ 允许直接用
SELECT中定义的别名排序，但低版本（如 5.7）可能报错Unknown column 'full_name' in 'order clause'，此时需改用表达式原样重写 - 对函数结果排序（如
ORDER BY YEAR(hire_date)）通常无法使用索引，属于“文件排序（filesort）”，大数据量时明显变慢 - 若排序依据是 JSON 字段中的某个键（如
ORDER BY info->>'$.dept'），需确保该路径稳定存在，否则空值或结构不一致会导致排序结果不可靠
真正容易被忽略的，是排序与索引的耦合关系：没有对应索引的 ORDER BY 在百万级以上表中可能让查询从毫秒级变成秒级，而这个瓶颈往往在测试环境因数据量小完全暴露不出来。
