在SQL查询里，ORDER BY的作用是对结果集进行排序。很多人习惯写ORDER BY column_name DESC，但当需求变得复杂，例如要把某个状态排在最前面、再按时间倒序、还要让空值靠后，单纯按列名排序就无法满足。其实ORDER BY支持表达式，可以在排序阶段计算每一行的排序键，再按计算结果排列。
理解ORDER BY的执行位置很重要。在标准SQL逻辑执行顺序中，ORDER BY位于SELECT之后，这意味着SELECT里的别名、计算列，在ORDER BY中通常可以直接引用。但更灵活的是，ORDER BY可以包含未出现在SELECT列表中的表达式，例如CASE WHEN status = 1 THEN 0 ELSE 1 END。数据库会先对每一行计算该表达式的值，然后按这个值排序，这也是复杂排序能实现的核心原因。
一、用CASE WHEN自定义业务优先级
实际业务中排序往往不是按照字段的自然大小，而是一种业务规则。例如订单状态有“待支付、已支付、已发货、已完成”，需要把待支付放最前，已完成放最后。这种需求可以用CASE WHEN在ORDER BY中生成一个顺序值。
假设orders表中有status字段，1代表待支付，2代表已支付，3代表已发货，4代表已完成。如果直接ORDER BY status ASC，1会在最前，这恰好符合。但如果业务要求已支付排最前，待支付第二，已完成最后，直接按status排序就不行。可以写：
SELECT order_id, status, created_at
FROM orders
ORDER BY
CASE status
WHEN 2 THEN 1
WHEN 1 THEN 2
WHEN 3 THEN 3
WHEN 4 THEN 4
ELSE 5
END,
created_at DESC;
上面的SQL用CASE表达式把每个状态映射成排序权重，2映射为1，表示已支付排最前。后面的created_at DESC是第二排序键，权重相同的行再按创建时间倒序。这就实现了业务自定义优先级，而不是依赖字段的原始排序。CASE WHEN不仅支持等值判断，还可以写范围条件，比如WHEN amount > 1000 THEN 1 WHEN amount > 500 THEN 2 ELSE 3 END，让大额订单优先显示。
这种写法维护成本较低。规则变化时只需要调整CASE表达式中的映射关系，不需要在应用层重新实现排序。但要注意CASE分支覆盖要完整，否则未命中的行会得到NULL，部分数据库默认把NULL排在最前面或最后面，可能导致顺序不符合预期。建议总是写ELSE兜底。
二、按多个字段运算结果排序
另一种复杂排序是对多个字段进行加权计算，按计算结果排序。比如商品表中有销量、评分、评论数，业务希望用一个综合热度值排序，而不是只按销量或只按评分。可以在ORDER BY中写算术表达式，让数据库按每行计算出的加权分数排列。
假设products表包含sales_count、rating、review_count，期望热度分数 = 销量权重0.5 + 评分权重0.3 + 评论数权重0.2。可以这样写：
SELECT product_id, product_name, sales_count, rating, review_count,
(sales_count * 0.5 + rating * 0.3 + review_count * 0.2) AS hot_score
FROM products
ORDER BY hot_score DESC;
这里直接在ORDER BY中引用了SELECT里的别名hot_score。大多数数据库如MySQL、PostgreSQL、SQL Server都支持ORDER BY别名。但为了兼容性，也可以重复写表达式：
SELECT product_id, product_name, sales_count, rating, review_count FROM products ORDER BY (sales_count * 0.5 + rating * 0.3 + review_count * 0.2) DESC;
第二种写法不依赖别名，数据库在排序时对每一行计算表达式值。需要注意的是，如果数据量很大，表达式排序无法利用普通索引，因为排序键是计算出来的，索引中并不存在这个值。此时数据库可能需要进行额外的排序操作，可以使用EXPLAIN查看执行计划是否出现filesort或sort操作。如果这种综合热度排序是常规需求，可以考虑在表中增加一个生成列或者维护一个热度字段，并为它建索引，以空间换时间。
另外，多字段排序中还可以混合升降序，例如ORDER BY category ASC, price DESC, sales_count DESC。这类场景如果字段本身有索引且排序方向一致，更容易走索引。但表达式排序会打断索引的有序性，需要酌情使用。
三、处理NULL值排序和函数排序
NULL值在排序中经常带来困扰。不同数据库对NULL的默认排序不一样：MySQL默认升序时NULL排最前，PostgreSQL默认升序时NULL排最后，Oracle默认升序时NULL排最后。要保证跨数据库行为一致，需要显式指定NULL的位置。
MySQL没有标准的NULLS FIRST语法，但可以用IS NULL表达式生成排序键，让空值排后：
SELECT employee_id, name, resignation_date FROM employees ORDER BY (resignation_date IS NULL) ASC, resignation_date ASC;
说明一下：resignation_date IS NULL在MySQL中返回1或0，非NULL返回0，NULL返回1。外层先按这个表达式升序，非NULL的0排在前面，NULL的1排在后面，然后再按日期升序。PostgreSQL和SQL Server则可以直接使用ORDER BY resignation_date ASC NULLS LAST，语法更简洁。了解不同数据库的差异，有助于写出可移植的SQL。
此外，ORDER BY还支持函数计算结果，比如按字符串长度排序、按日期中的某一部分排序。例如按姓名的拼音长度排序：ORDER BY CHAR_LENGTH(name) DESC；或者按注册日期的月份排序：ORDER BY MONTH(created_at)。函数排序和表达式排序一样，对每一行计算函数返回值再排序，同样无法直接利用字段索引。对于此类排序，如果数据量级较大，应当考虑是否可以在写入时把计算结果保存下来。
四、复杂排序的索引影响与优化建议
ORDER BY表达式虽然灵活，但它对索引的影响必须清楚。数据库索引通常按照列值有序存储，当ORDER BY使用列本身且排序方向与索引一致时，可以避免额外排序。一旦ORDER BY中出现表达式、函数或CASE WHEN，排序键就变成计算结果，普通索引无法直接提供有序性，数据库只能先读取数据，再对结果集排序。
如果结果集不大，这种额外排序成本可以忽略。但当表达到百万级时，排序可能会消耗大量内存和临时磁盘空间。针对这种情况，有几种优化思路。第一，把常用的排序表达式固化为表字段。例如前面提到的热度分数，可以在写入时计算好存入hot_score列，并为该列建立索引，ORDER BY直接使用列排序。第二，利用函数索引。PostgreSQL、Oracle等数据库支持基于表达式的索引，例如CREATE INDEX idx_order_status ON orders ((CASE status WHEN 2 THEN 1 WHEN 1 THEN 2 ELSE 9 END))，这样CASE表达式排序也可能走索引。MySQL 8.0也支持函数索引，但需要注意版本。
第三，尽量缩小排序范围。先在WHERE中过滤出必要的行，再对较小的结果集做表达式排序。例如不要全表排序后取前10条，而是先通过索引筛选最近一个月的数据，再按表达式排序。第四，检查执行计划。可以用EXPLAIN或EXPLAIN ANALYZE查看是否出现了Using filesort、Sort Method等信息，判断排序代价。总而言之，表达式排序是解决问题的手段，不是随时随地都可以无成本使用的工具，结合业务场景和数据量选择合适方案，才能写出高效且可维护的SQL。
SQL排序ORDER BY表达式多条件排序修改时间：2026-09-25 23:41:41