Elasticsearch深度分页优化与search_after游标查询实战

Elasticsearch深度分页的性能瓶颈

Elasticsearch默认分页查询使用from+size参数，from表示跳过文档数，size表示返回文档数。当from值很大时（如from=10000, size=10），协调节点需要从每个分片取回from+size条文档做全局排序，再截取目标页的10条数据。5个分片的集群查询from=10000意味着每个分片返回10010条文档，协调节点合并排序50050条后丢弃50040条，网络传输和内存开销随from值线性增长。Elasticsearch默认限制from+size不超过10000，超出即报ResultWindowException。深度分页优化是Elasticsearch大数据量查询的核心运维技能。

三种深度分页方案对比

方案一：增大index.max_result_window。最简单但不推荐，将限制调到50000甚至更高，查询延迟从毫秒级飙升到秒级，协调节点OOM风险增大。仅适用于数据量小、并发低的场景。

方案二：scroll API。创建快照游标逐批拉取数据，适合离线导出和批量处理，但不支持实时跳页。每次scroll请求返回下一批数据和一个scroll_id，客户端用scroll_id继续拉取。scroll会占用资源维持快照一致性，必须设置合理的过期时间并在使用后主动清除：

GET /products/_search?scroll=2m
{
"size": 1000,
"query": { "match_all": {} }
}

# 使用完毕后清除
DELETE /_search/scroll
{
"scroll_id": ["DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4W..."]
}

方案三：search_after游标查询。推荐方案，支持实时查询且性能稳定。search_after利用排序字段的值作为游标，每次查询传入上一页最后一条文档的排序值，Elasticsearch直接定位到该位置向后取数据，避免跳过大量文档。

search_after查询实战

search_after要求查询必须包含唯一排序字段（通常用_sort字段或_id作为兜底），确保游标值唯一。第一次查询不加search_after：

GET /orders/_search
{
"size": 20,
"query": {
"bool": {
"filter": [
{ "range": { "create_time": { "gte": "2026-08-01" } } }
]
}
},
"sort": [
{ "create_time": "desc" },
{ "_id": "asc" }
]
}

返回结果中每条hit的sort数组就是该文档的排序值。取最后一页的sort值作为下一页的search_after：

GET /orders/_search
{
"size": 20,
"query": {
"bool": {
"filter": [
{ "range": { "create_time": { "gte": "2026-08-01" } } }
]
}
},
"sort": [
{ "create_time": "desc" },
{ "_id": "asc" }
],
"search_after": [
1723318400000,
"order_92837"
]
}

search_after的核心优势：协调节点不需要合并大量文档，每个分片只需从排序值的位置向后扫描size条数据，查询复杂度与from无关，翻到第1000页和第1页的延迟几乎相同。

前端跳页需求的实现方案

search_after不支持随机跳转到指定页码，只支持上一页/下一页的顺序翻页。对于必须跳页的业务场景（如订单管理后台跳转到第50页），有以下方案：方案一，维护游标缓存。在Redis中按查询条件缓存每一页的search_after值，用户跳页时从缓存取游标。方案二，辅助索引表。将排序字段和页码映射写入辅助表，跳页时先查辅助表获取游标值。方案三，混合策略。前100页用from+size（延迟可控），超出100页后切换到search_after并限制只能顺序翻页，这是大多数业务系统实际采用的折中方案。

search_after常见问题与调优

排序字段含null值时，null值默认排在最后（升序）或最前（降序），会导致游标定位不准。解决方式：用missing参数指定null值的排序位置，或写入时用默认值替代null。排序字段不唯一时，search_after可能跳过或重复文档，务必添加_id作为第二排序字段。索引有新文档写入时，search_after可能出现文档漂移（新写入文档排序值在当前游标之前，下一页看不到该文档）。对实时性要求高的场景，可以用point-in-time（PIT）API创建数据快照，search_after配合PIT查询保证结果一致性：

POST /orders/_pit?keep_alive=10m

GET /_search
{
"pit": { "id": "some-pit-id", "keep_alive": "10m" },
"size": 20,
"sort": [{ "create_time": "desc" }, { "_id": "asc" }],
"search_after": [1723318400000, "order_92837"]
}

PIT会占用资源，使用后需及时清除。Elasticsearch 8.x版本中PIT与search_after配合是深度分页的推荐方案。