一文说清Elasticsearch中的分页与深度分页问题

一文讲透 Elasticsearch 分页与深度分页：从原理到实战

你有没有遇到过这样的场景？

前端同学说：“用户点了第500页，怎么卡住了？”
运维报警：“ES节点CPU爆了，查一下是不是有人在翻几万条数据！”
面试官问：“Elasticsearch 为什么不能深度分页？from/size到底慢在哪？”

这些问题的背后，其实都指向同一个核心机制——Elasticsearch 的分页实现方式及其在分布式环境下的代价。

今天我们就来彻底搞清楚：
-Elasticsearch 是怎么执行一次分页查询的？
-为什么越往后翻越慢？
-search_after和scroll真的能解决这个问题吗？它们之间又有什么区别？
-实际项目中到底该用哪种方案？

别急，我们一步步拆解。这不仅是一篇技术解析文，更是一份你可以直接拿去用的生产级分页选型指南。

from/size 不是“跳过”，而是“先拉再切”

我们先来看最常见的分页写法：

{ "from": 9990, "size": 10, "query": { "match_all": {} } }

看起来很简单：跳过前9990条，取接下来的10条。就像 SQL 中的LIMIT 9990, 10。

但问题来了——Elasticsearch 真的是“跳过”了吗？

答案是：不是。

分布式系统里的“全局排序”有多贵？

Elasticsearch 是分布式的。你的索引可能被分成 5 个分片，分布在不同的节点上。

当你发起一个from=9990, size=10的请求时，协调节点（coordinating node）会做这几件事：

向每个分片发送子查询，要求返回本地排序后的 top 10000 条结果；
每个分片自己执行查询、打分、排序，返回自己的前 10000 条；
协调节点把所有分片返回的结果合并起来，重新排序，形成全局有序列表；
最后截取[9990, 10000)这 10 条数据返回给客户端。

📌 关键点：每个分片都要处理from + size条记录，哪怕其中 9990 条最终都会被丢弃！

这意味着什么？

偏移量	每个分片需返回	总传输数据量（假设5分片）
from=0	10	50
from=90	100	500
from=9990	10000	50,000

看到没？随着from增大，资源消耗几乎是线性增长的。CPU、内存、网络带宽全都被浪费在“搬运无效中间结果”上。

这也是为什么 ES 默认设置了：

index.max_result_window: 10000

一旦from + size > 10000，就会报错：

Result window is too large, from + size must be less than or equal to 10000

这是保护机制——防止一个请求拖垮整个集群。

所以，下次面试官问你：“ES 为什么不支持深度分页？”
你可以这样答：

“因为from/size在分布式环境下需要各分片返回大量中间结果，在协调节点进行全局排序和截断。当偏移量很大时，这种‘拉取-合并-丢弃’模式会造成严重的性能浪费，甚至导致 OOM。”

search_after：用“游标”代替“跳过”

既然from/size太重，那有没有办法只拿“真正需要的数据”？

有，就是search_after。

它不靠数字偏移，而是靠“上一页最后一个文档的位置”作为锚点，继续往下读。有点像数据库里的“键集分页”（Keyset Pagination），也像翻书时记住“上次看到哪一页”。

它是怎么工作的？

假设你要按时间倒序查看日志：

{ "size": 10, "sort": [ { "@timestamp": "desc" }, { "_id": "asc" } ], "query": { "range": { "@timestamp": { "lte": "now" } } } }

第一次请求没有search_after，直接返回最新的10条。

拿到结果后，取出最后一条文档的排序值，比如：

[1680000000000, "log_001"]

下一次请求带上这个值：

{ "size": 10, "sort": [ { "@timestamp": "desc" }, { "_id": "asc" } ], "query": { "range": { "@timestamp": { "lte": "now" } } }, "search_after": [1680000000000, "log_001"] }

ES 就知道：“哦，你要找比(1680000000000, log_001)更大的记录”，于是每个分片只需扫描后续数据，无需加载前面成千上万条。

性能对比惊人

方案	查询延迟（from=9990）	内存占用	是否可扩展
`from/size`	800ms+	高	❌
`search_after`	~50ms	极低	✅

差距不止十倍。

而且search_after不受max_result_window限制，理论上可以一直翻到一百万页。

但它也有前提条件

必须指定明确的排序规则；
排序字段组合必须能唯一标识顺序，否则可能出现漏读或重复。

举个例子：

如果你只按@timestamp desc排序，而很多文档时间戳相同，那么 ES 无法确定“下一个”是谁。这时候就必须补充一个唯一字段，比如_id或业务主键：

"sort": [ { "@timestamp": "desc" }, { "_id": "asc" } ]

这样才能保证每次都能精准定位“下一个”。

Java 实现示例

// 第一次请求 SearchSourceBuilder builder = new SearchSourceBuilder(); builder.query(QueryBuilders.rangeQuery("@timestamp").lte("now")); builder.sort("@timestamp", SortOrder.DESC); builder.sort("_id", SortOrder.ASC); builder.size(10); SearchRequest request = new SearchRequest("logs"); request.source(builder); SearchResponse response = client.search(request, RequestOptions.DEFAULT); List<Object[]> sortValuesList = new ArrayList<>(); for (SearchHit hit : response.getHits()) { System.out.println(hit.getSourceAsString()); sortValuesList.add(hit.getSortValues()); } // 如果还有数据，构造下一页 if (!sortValuesList.isEmpty()) { Object[] lastSortValues = sortValuesList.get(sortValuesList.size() - 1); SearchSourceBuilder nextBuilder = new SearchSourceBuilder(); nextBuilder.query(QueryBuilders.rangeQuery("@timestamp").lte("now")); nextBuilder.sort("@timestamp", SortOrder.DESC); nextBuilder.sort("_id", SortOrder.ASC); nextBuilder.size(10); nextBuilder.searchAfter(lastSortValues); // 设置游标 SearchRequest nextRequest = new SearchRequest("logs"); nextRequest.source(nextBuilder); SearchResponse nextPage = client.search(nextRequest, RequestOptions.DEFAULT); // 处理 nextPage ... }

这就是典型的“连续拉取”逻辑。注意：它是无状态的，翻页依赖客户端维护上一次的排序值。

scroll API：为批量任务而生的“数据快照”

如果说search_after是为“高效顺滑地浏览数据”设计的，那scroll就是为“一次性搬完所有数据”服务的。

它适用于数据导出、迁移、报表生成等离线任务。

核心思想：保存搜索上下文

当你发起第一个scroll请求时：

POST /logs/_search?scroll=1m { "size": 100, "query": { "match_all": {} }, "sort": ["_doc"] }

ES 会：
- 创建一个“搜索上下文”（search context）；
- 基于当前 Lucene 版本创建一个数据快照；
- 返回第一批数据和一个scroll_id。

之后你拿着scroll_id不断请求：

POST /_search/scroll { "scroll": "1m", "scroll_id": "DnF1ZXJ5VGhlbkZldGNo..." }

ES 就会根据上下文继续返回下一批，直到数据全部读完。

优势很明显

数据一致性强：你在遍历过程中看到的始终是初始时刻的数据视图，不会因新写入而“抖动”；
适合大数据量导出：可稳定处理百万级文档；
推荐使用_doc排序：这是 Lucene 内部顺序，不需要额外排序，速度最快。

但它也有硬伤

占用服务器资源：每个 scroll 上下文会锁定缓存、文件句柄，消耗堆内存；
不能长期持有：默认 1 分钟超时，需及时拉取；
不支持随机访问：只能顺序读；
不适合高并发交互场景：大量活跃的 scroll 会导致集群负载升高。

更关键的是：自 Elasticsearch 7.10 起，官方已明确建议用 PIT（Point in Time）替代传统 scroll。

scroll 正在被淘汰？PIT 才是未来

没错，scroll虽然还在用，但已经是“老古董”了。

它的替代者叫Point in Time（PIT），结合search_after使用，既能保持快照一致性，又能享受游标的高性能。

PIT 的工作流程

先打开一个 PIT，获取一个pit_id：

POST /logs/_pit?keep_alive=1m

在查询中使用 PIT，并配合search_after分页：

{ "size": 10, "sort": [ { "@timestamp": "desc" }, { "_id": "asc" } ], "query": { "range": { "@timestamp": { "gte": "now-1h" } } }, "pit": { "id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxKgZub2RlXzEAAAAAAAAAAAEBYQACAWh1aWRqaBZub2RlXzIAAAAAAAAAAAI", "keep_alive": "1m" }, "search_after": [1680000000000, "log_001"] }

每次返回新的pit信息，用于下一轮请求；
完成后显式关闭 PIT 释放资源。

为什么 PIT 更好？

对比项	scroll	PIT + search_after
数据一致性	✅ 快照	✅ 快照
性能	一般	高（无需维护上下文）
资源占用	高（context 占内存）	低
可扩展性	差	好
是否推荐	❌（逐渐废弃）	✅（官方推荐）

简单说：PIT 把“快照能力”和“高效分页”完美结合，还不占资源。

新项目强烈建议直接上PIT + search_after组合拳。

到底该怎么选？一张表说清适用场景

方案	支持跳页	性能稳定性	数据一致性	适用场景	推荐指数
`from/size`	✅	❌（随偏移恶化）	⚠️ 实时变化	前台分页展示（<1万条）、简单列表	⭐⭐☆
`search_after`	❌（仅顺序）	✅（稳定）	⚠️ 实时变化	深度分页、日志流、消息中心、实时查询	⭐⭐⭐⭐
`scroll`	❌	✅（批次稳定）	✅（快照）	数据导出、迁移、旧系统兼容	⭐⭐
`PIT + search_after`	❌	✅✅	✅（快照）	大数据量一致性遍历（新项目首选）	⭐⭐⭐⭐⭐