在关系型数据库查询中，排序是最基础也最常用的操作之一。当业务要求结果集先按照某个维度归类、再在同类中按另一维度排名时，单字段排序就无能为力了。SQL提供的ORDER BY子句支持同时指定多个字段，并且每个字段都可以独立选择升序（ASC）或降序（DESC），这种组合能力是报表统计和明细查询的基石。
一、ORDER BY多字段语法结构
标准SQL中，ORDER BY后面可以跟多个用逗号分隔的排序项，每一项由字段名和可选的排序方向组成。数据库引擎会严格按照书写顺序作为优先级：先比较第一个字段，值相同才继续比较第二个字段，以此类推。如果某项没有写ASC或DESC，则默认采用ASC。
下面这段示例在员工表中，先按部门编号升序排列，同一部门内再按入职时间降序排列，让资深员工排在前面：
SELECT emp_id, dept_id, hire_date, salary FROM employee ORDER BY dept_id ASC, hire_date DESC;
上述写法中，dept_id决定大次序，只有两条记录dept_id相等时，hire_date的降序才生效。这种显式声明ASC和DESC的做法，比依赖默认值更清晰，也方便后续维护。
1.1 默认排序方向说明
不少初学者会忽略一点：不写排序方向并不代表“不排序”，而是等价于ASC。在跨数据库迁移脚本时，如果原逻辑依赖某种隐式顺序，最好全部补全方向关键字，避免不同客户端工具带来的阅读偏差。
同时，多字段排序里每个字段的方向是独立的。完全可以出现“字段A升序、字段B降序、字段C升序”的混合模式，数据库不会因为它们方向相反而报错。
二、ASC与DESC混合组合实践
实际业务中，混合排序非常普遍。例如电商后台想要“同店铺中，销量高的靠前；销量相同时，最新上架的靠前”，就可以让销量降序、上架时间降序；若希望老商品优先曝光，则上架时间改为升序。
以下代码演示了商品表按店铺升序、销量降序、创建时间升序的组合：
SELECT shop_id, goods_id, sales_count, create_time FROM goods ORDER BY shop_id ASC, sales_count DESC, create_time ASC;
执行时，数据库先划分店铺，店铺内部先比销量，销量一致再用创建时间正序破平。这种结构在排行榜、工单列表等场景几乎必备。需要注意的是，字段顺序一旦调换，语义就完全变了，比如把create_time放最前，就变成全局按时间排，店铺和销量失去优先意义。
2.1 使用表达式排序
ORDER BY后的项不限于裸字段，也可以是函数或计算表达式，且同样能指定ASC/DESC。比如按“工资加奖金”的总收入降序：
SELECT emp_id, salary, bonus FROM employee ORDER BY (salary + bonus) DESC, emp_id ASC;
这里先计算总收入再排序，emp_id仅用于总收入相同时稳定输出。表达式排序在统计类查询中很灵活，但也要注意索引可能失效，数据量大时需评估性能。
三、NULL值在多字段排序中的表现
多字段排序还有一个容易踩坑的地方：NULL怎么排。不同数据库策略不同。MySQL在ORDER BY中把NULL当作最小值，因此ASC时NULL排最前，DESC时NULL排最后；而PostgreSQL默认NULL在最后，但可用NULLS FIRST或NULLS LAST显式控制。
为兼容性与可读性，建议在使用多字段且字段允许为空时，主动声明NULL位置：
-- PostgreSQL示例 SELECT dept_id, salary FROM employee ORDER BY dept_id ASC NULLS LAST, salary DESC NULLS LAST;
在MySQL中虽然没有NULLS LAST语法，但可以利用函数将NULL转为特定值，例如用COALESCE(dept_id, 9999)间接实现“空值靠后”。跨库开发时，一定要先确认目标库的NULL排序规则，否则多字段结果会出现难以察觉的错位。
3.1 排序稳定性与分页
当多字段仍无法唯一确定顺序时，数据库不保证每次返回的物理顺序一致，这在LIMIT分页时会导致重复或漏数据。解决办法是最后追加一个唯一键，如主键，作为终极排序字段：
SELECT id, dept_id, salary FROM employee ORDER BY dept_id ASC, salary DESC, id ASC LIMIT 10 OFFSET 0;
这样无论底层执行计划如何调整，同一页数据始终是确定的，前端翻页不会跳行。这也是多字段排序在生产环境落地的一个关键细节。
四、性能与索引建议
多字段排序能否命中索引，取决于索引的字段顺序和方向与ORDER BY是否匹配。比如建立了(dept_id ASC, hire_date DESC)的联合索引，那么对应方向的ORDER BY就能避免额外排序动作；若顺序颠倒或方向冲突，数据库往往要再做一次filesort，数据量大时延迟明显。
可以通过EXPLAIN观察Extra列是否出现Using filesort来判断。下面简单对比有索引与无索引的执行差异：
| 场景 | ORDER BY写法 | 索引情况 | 典型Extra |
|---|---|---|---|
| 精准匹配 | dept_id ASC, hire_date DESC | 有联合索引同序 | Using index |
| 顺序颠倒 | hire_date DESC, dept_id ASC | 有联合索引 | Using filesort |
| 无索引 | dept_id ASC, salary DESC | 无相关索引 | Using filesort |
从表中可以看出，写ORDER BY不是“能跑就行”，字段排列应尽量贴合常用查询的索引设计。当必须按不在索引里的字段混合排序时，可考虑冗余字段或物化视图来转移计算成本。
4.1 减少不必要的排序字段
每多一个排序字段，比较开销和临时空间都会增加。如果业务上某字段在前面字段确定后几乎不会重复，就无需再往后加。例如按唯一订单号排序后，没必要再补用户ID。精简ORDER BY列表，是简单有效的优化手段。
综上，SQL多字段排序的关键在于理解“从左到右的优先级”和“每字段独立方向”。在书写时显式标出ASC/DESC，处理好NULL与分页稳定性，并结合索引顺序来设计，就能写出既准确又高效的多条件排序语句。