使用search_after参数实现需求的具体操作步骤
- 构建查询语句：
- 以Elasticsearch为例，假设索引名为
ecommerce_index。
- 首先构建基本的查询结构，指定要查询的字段以及排序规则：
{
"size": 10,
"sort": [
{
"price": {
"order": "desc"
}
},
{
"sales": {
"order": "asc"
}
}
],
"query": {
"match_all": {}
}
}
- 上述查询语句中，
size指定每页展示10条数据，sort中先按price字段降序排序，再按sales字段升序排序，query使用match_all查询所有文档。
- 处理翻页：
- 第一页：直接发送上述查询语句，Elasticsearch会返回符合排序规则的前10条数据。在返回结果中，会包含每条数据的排序值。例如，返回结果类似如下：
{
"took": 10,
"timed_out": false,
"hits": {
"total": {
"value": 100,
"relation": "eq"
},
"max_score": null,
"hits": [
{
"_index": "ecommerce_index",
"_id": "1",
"_score": null,
"_source": {
"product_name": "Product A",
"price": 100,
"sales": 10
},
"sort": [
100,
10
]
},
// 其他9条数据...
]
}
}
- 后续页：要获取下一页数据，需要使用
search_after参数。search_after的值是上一页最后一条数据的排序值数组。例如，上例中第一页最后一条数据的排序值为[100, 10]（假设这是最后一条数据的price和sales值），那么获取第二页数据的查询语句如下：
{
"size": 10,
"sort": [
{
"price": {
"order": "desc"
}
},
{
"sales": {
"order": "asc"
}
}
],
"query": {
"match_all": {}
},
"search_after": [100, 10]
}
- 每次获取下一页时，都更新
search_after的值为上一页最后一条数据的排序值，以此类推获取后续页数据。
search_after相比于其他分页方式的优势
- 避免深度分页问题：传统的
from + size分页方式在深度分页（from值很大）时，性能会急剧下降，因为Elasticsearch需要从所有分片上收集并排序大量数据。而search_after是基于上一页最后一条数据的排序值来定位下一页数据，不需要在服务端存储分页状态，性能更优，尤其适用于大数据量分页场景。
- 实时性较好：由于
search_after是基于文档的排序值进行分页，在数据实时更新的情况下，能更及时地反映数据变化。相比之下，from + size分页方式如果数据在查询过程中发生变化，可能会出现重复或遗漏数据的情况。
search_after可能存在的问题
- 排序值唯一性要求：
search_after依赖排序值来定位下一页数据，如果排序值不是唯一的（例如有多个商品价格和销量都相同），可能会导致数据遗漏或重复。在这种情况下，需要确保排序字段的组合能够唯一标识每一条数据，或者在查询时添加额外的唯一标识字段作为排序依据。
- 前端状态管理复杂：客户端需要存储上一页最后一条数据的排序值，并在每次请求下一页时携带，增加了前端状态管理的复杂度。相比
from + size分页方式，前端只需要控制页码和每页数量，search_after的使用需要更多的前端逻辑处理。
