Elasticsearch的查询结果默认是按照相关性得分（_score）从高到低返回的，这在全文检索场景下很合理。可一旦到了业务系统里，需求就变了：商品列表要按价格升序、订单列表要按创建时间倒序、排行榜要按销量和评分组合排序。这些都需要用到查询DSL中的sort参数。sort看起来简单，直接写个字段名加asc或desc就行，但背后涉及字段类型限制、doc_values机制、嵌套文档处理、相关性得分缺失等一系列细节，稍不注意就会踩坑。这篇文章把sort参数的常用配置和典型场景梳理一遍。
sort参数的基础语法与使用前提
sort参数可以出现在search请求体中，和query平级。最基本的写法是给一个字段数组，每个元素指定排序字段和顺序。例如按价格升序、同价时按创建时间倒序：
GET /products/_search
{
"query": {
"match_all": {}
},
"sort": [
{ "price": { "order": "asc" } },
{ "created_at": { "order": "desc" } }
]
}
如果只需要按单个字段排序，也可以简写成"sort": "price"或者"sort": [{"price": "desc"}]，效果完全一样。默认不写order时，排序方向是asc升序。
需要特别注意的是排序对字段类型的要求。并不是所有字段都能排序，能够参与排序的字段必须是启用了doc_values的类型，包括数值类型（integer、long、float、double）、keyword、date、boolean、ip等。text类型字段默认是不能直接排序的，因为text会被分词器拆成多个词项，Elasticsearch无法确定该按哪个词排。如果确实需要对text字段排序，通常有两种做法：一是给字段加一个keyword子字段，排序时用product_name.keyword；二是利用fielddata，在查询时把分词后的词项加载到内存构建正排索引，但这种方式非常消耗堆内存，生产环境基本不推荐。
如果对一个没有doc_values的字段执行排序，会直接抛出类似Fielddata is disabled on [xxx] in [xxx]的异常，遇到这个报错就要先回头检查mapping里字段的定义。
多字段排序、missing值处理与mode参数
多字段排序时，数组中的顺序就是优先级顺序：先按第一个字段排，只有第一个字段值相同时才看第二个字段，以此类推。建议把区分度高的字段放前面，最后一个排序条件可以放_id保证分页稳定性。
实际数据里难免有缺失值，sort提供了missing参数来控制缺失字段的文档排在哪一头，可选值有_last（默认，排在最后）、_first（排在最前）以及自定义值。例如部分商品没有价格字段，希望它们排在列表末尾：
GET /products/_search
{
"query": { "match_all": {} },
"sort": [
{
"price": {
"order": "asc",
"missing": "_last"
}
}
]
}
对于数值和date类型，还可以用unmapped_type来容忍字段不存在的情况：当索引里根本没有这个mapping时，排序不会直接报错，而是按指定类型处理，所有文档视为缺失值。这在跨多个结构不完全一致的索引查询时很有用。
另一个常用的参数是mode，它解决的是数组字段或多值字段的排序问题。当一个文档的字段有多个值（比如一个商品有多个标签权重），Elasticsearch需要知道取哪个值参与排序。mode支持min、max、sum、avg、median几种模式。比如按多个评分中的最高分排序：
GET /products/_search
{
"sort": [
{
"scores": {
"order": "desc",
"mode": "max"
}
}
]
}
按嵌套字段排序与基于脚本的自定义排序
嵌套文档（nested类型）内部的字段排序需要配合nested参数，同时指定嵌套路径和过滤条件。典型场景是商品有多个规格（颜色、尺寸、价格），希望按符合条件的规格价格排序，比如按红色的最低价排：
GET /products/_search
{
"query": { "match_all": {} },
"sort": [
{
"variants.price": {
"order": "asc",
"mode": "min",
"nested": {
"path": "variants",
"filter": {
"term": { "variants.color": "red" }
}
}
}
}
]
}
这里的nested.path指明排序字段所在的嵌套层级，filter则限定参与排序的嵌套子文档范围，mode取min表示在这些符合条件的子文档里挑最小价格。不加nested配置直接对嵌套字段排序会报错，这是新手最容易撞上的问题之一。
当排序逻辑无法用单一字段表达时，可以借助_script排序，用Painless脚本动态计算排序值。比如根据销量和评分加权出一个热度分：
GET /products/_search
{
"query": { "match_all": {} },
"sort": {
"_script": {
"type": "number",
"script": {
"lang": "painless",
"source": "doc['sales'].value * 0.6 + doc['rating'].value * 100 * 0.4"
},
"order": "desc"
}
}
}
脚本排序灵活但代价明显：每次查询都要逐文档执行脚本，无法利用doc_values的预排序结构，数据量大时性能会明显下降。能用字段排序解决的需求尽量别上脚本，脚本排序适合逻辑确实复杂的兜底场景。
排序后的得分处理与常见问题排查
一旦指定了sort，返回结果里文档的_score就会被设为null，因为Elasticsearch默认不再计算相关性得分，这本身就是一种性能优化。如果既想要相关性得分又想要自定义排序，可以在sort里显式加上"_score": {"order": "desc"}，或者在查询参数中设置track_scores为true。
分页深度较大时，排序字段的选择还会影响性能。from加size的分页方式下，每个分片都要取回from加size条排序后的数据，再在协调节点归并。排序字段如果是高基数字段问题不大，但要是配合脚本排序或者fielddata，深分页的代价会成倍放大，这时候应该考虑search_after配合排序值做游标式翻页。
最后汇总几个高频问题的排查思路。第一，报错说字段不可排序，先确认mapping类型，text字段改用子字段keyword。第二，排序结果看起来是乱的，检查字段是否被分词、是否有多个值但没设置mode、是否忽略了missing值的位置。第三，跨索引查询时报No mapping found for field，用unmapped_type参数规避。第四，排序后_score全是null，属于正常现象，需要得分就显式加_score排序或开启track_scores。把这些细节掌握住，sort参数基本就能覆盖绝大多数业务排序需求了。
Elasticsearch sortelasticsearch排序sort参数修改时间：2026-09-03 12:48:58