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在百万级以上表中可能让查询从毫秒级变成秒级，而这个瓶颈往往在测试环境因数据量小完全暴露不出来。
