# 一次讲透 Elasticsearch 分页：from/size、search_after、PIT 与 Scroll

```text
旧方案：所有分页都用 from/size
冲突：深分页越来越慢，Scroll 又被用户点击“下一页”误用
后果：接口超时、内存飙升、翻页结果跳动
```

很多团队把 Elasticsearch 当 MySQL 用，分页一律 from/size。前几页没问题，一旦用户点到第 50 页，延迟从几十毫秒涨到几秒。

我是老李，过去在广告投放系统里见过运营同学翻第 200 页导出名单，直接把查询节点内存打满。

为什么深分页会越来越慢？

普通用户点击“下一页”，该选 search_after 还是 Scroll？

如果选错，会出现什么后果？

# 01、故事

```text
凌晨 01:47→广告后台→导出第 180 页→查询节点内存飙到 92%
```

那天凌晨我在值班，任务是保证广告后台查询服务稳定。

运营同学在后台反复点击“下一页”，想找到一批异常点击记录。

点到第 180 页时，页面一直转圈。

紧接着监控告警：ES 查询节点堆内存使用率 92%，Young GC 频率从每分钟 3 次飙到 40 次。

我打开慢日志，发现同一个查询已经跑了 11 秒还没返回。

> 深夜告警催人醒，
> 翻页深处藏祸根。
> 莫把搜索当库使，
> 数据访问要分层。

# 02、问题

```text
需求变化：从“看前几页”变成“翻到几百页”
冲突：from/size 深分页需要跳过并丢弃大量结果
后果：CPU、内存、延迟同时恶化
```

from/size 的语义是：协调节点从每个分片取 from+size 条文档，汇总排序后丢弃前 from 条。

翻到第 180 页、每页 20 条时，每个分片要取 3600 条。

如果索引有 5 个主分片，协调节点需要排序 18000 条文档，只为返回最后 20 条。

页越深，丢弃越多，内存和 CPU 成本线性甚至超线性增长。

可验证的验收标准：同一查询第 1 页 P99 小于 80ms，第 180 页 P99 小于 500ms，且查询节点堆内存峰值不超过 75%。

> 浅页轻松如饮水，
> 深页沉重似登山。
> 不是索引变慢了，
> 是丢弃成本在翻番。

# 03、原理

```text
核心机制：分页是“定位”，遍历是“游标”
```

from/size 是随机访问模型：每次请求都重新计算排名，再跳到指定偏移。

search_after 是顺序访问模型：用上一页最后一条的排序值作为游标，只读取游标之后的数据。

PIT 是时间一致性模型：把索引在某个时间点的视图冻结，翻页期间不因写入、刷新、合并而变化。

Scroll 是批量扫描模型：创建快照上下文，用 scroll_id 顺序拉取全部匹配文档。

反直觉判断：search_after 不是“分页”，它不承诺总页数，也不支持跳页。

> 定位靠偏移，
> 游标靠顺序。
> 快照保一致，
> 扫描为批量。

# 04、架构

```text
输入：查询条件+排序键+游标/偏移
本模块：分页策略选择器
输出：结果页+下一页游标/scroll_id
边界：不负责业务过滤、不负责权限裁剪
```

架构上把“产品分页概念”和“引擎访问策略”拆开。

产品层只关心：当前第几页、每页多少条、总条数大概多少。

引擎层关心：用 from/size、search_after、PIT 还是 Scroll 取数。

浅分页用 from/size，收益是简单、支持跳页、总条数准确。

深分页用 search_after，收益是延迟稳定，代价是不能跳页。

需要一致性快照时叠加 PIT，代价是占用额外资源保存索引视图。

全量导出用 Scroll，收益是吞吐高，代价是快照上下文占用堆内存。

适用条件：单次遍历数据量超过 10000 条，或用户可能翻到 50 页以后。

> 产品要页码，
> 引擎要游标。
> 两层各司职，
> 深翻不再崩。

# 05、第一版实战

```text
环境→配置→代码→启动→验证→V1
```

环境：Elasticsearch 8.11.3，Spring Boot 3.2.1，spring-boot-starter-data-elasticsearch。

依赖配置：

```xml
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-elasticsearch</artifactId>
</dependency>
```

连接配置：

```yaml
spring:
  elasticsearch:
    uris: http://localhost:9200
    username: elastic
    password: changeme
```

索引映射：

```json
PUT /ad_click
{
  "mappings": {
    "properties": {
      "campaign_id": { "type": "keyword" },
      "user_id": { "type": "keyword" },
      "click_time": { "type": "date" },
      "cost_micros": { "type": "long" }
    }
  }
}
```

写入 20 万条测试数据：

```bash
for i in $(seq 1 200000); do
  curl -s -u elastic:changeme -X POST "http://localhost:9200/ad_click/_doc" \
    -H 'Content-Type: application/json' \
    -d "{\"campaign_id\":\"camp_$((i % 100))\",\"user_id\":\"user_$((i % 50000))\",\"click_time\":\"2025-01-01T00:00:00Z\",\"cost_micros\":$((RANDOM % 10000))}" > /dev/null
done
```

V1 查询代码：

```java
public Page<AdClick> pageByFromSize(int page, int size) {
    PageRequest pageRequest = PageRequest.of(page, size,
            Sort.by(Sort.Direction.DESC, "click_time")
                .and(Sort.by(Sort.Direction.DESC, "_id")));
    Query query = NativeQuery.builder()
            .withQuery(QueryBuilders.matchAllQuery())
            .withPageable(pageRequest)
            .build();
    SearchHits<AdClick> hits = operations.search(query, AdClick.class);
    return SearchHitSupport.searchPageFor(hits, pageRequest);
}
```

启动应用后验证第 1 页：

```bash
curl -s -u elastic:changeme "http://localhost:9200/ad_click/_search" \
  -H 'Content-Type: application/json' \
  -d '{"from":0,"size":20,"sort":[{"click_time":"desc"},{"_id":"desc"}]}'
```

示例输出：

```text
{
  "took": 18,
  "hits": { "total": { "value": 200000 }, "hits": [ ... 20 条 ... ] }
}
```

第 1 页成功标准：took 小于 80ms，返回 20 条，total 为 200000。

再验证第 5000 页：

```bash
curl -s -u elastic:changeme "http://localhost:9200/ad_click/_search" \
  -H 'Content-Type: application/json' \
  -d '{"from":99980,"size":20,"sort":[{"click_time":"desc"},{"_id":"desc"}]}'
```

示例输出：

```text
{
  "took": 3200,
  "hits": { "total": { "value": 200000 }, "hits": [ ... 20 条 ... ] }
}
```

V1 结论：第 1 页 18ms，第 5000 页 3.2 秒，深分页不可接受。

> 首版跑通心欢喜，
> 浅页响应如闪电。
> 深页一测傻了眼，
> 三秒延迟在眼前。

# 06、排查

```text
诊断树
├─ 现象：深分页 took 从 18ms 涨到 3200ms
│  ├─ 怀疑：索引未刷新？
│  │  └─ 检查：_refresh 后复测，延迟不变
│  ├─ 怀疑：排序字段无索引？
│  │  └─ 检查：click_time 是 date 类型，_id 默认索引
│  ├─ 怀疑：协调节点内存不足？
│  │  └─ 检查：堆内存 92%，GC 频繁
│  └─ 根因：from/size 深分页丢弃成本过高
└─ 修复：改用 search_after + PIT
```

第一个怀疑是索引没刷新，执行：

```bash
curl -s -u elastic:changeme -X POST "http://localhost:9200/ad_click/_refresh"
```

复测第 5000 页，took 仍然 3 秒以上，排除刷新问题。

第二个怀疑是排序字段没建索引，查看映射：

```bash
curl -s -u elastic:changeme "http://localhost:9200/ad_click/_mapping" | grep -A5 click_time
```

click_time 是 date 类型，默认 doc_values 开启，排除索引问题。

第三个怀疑是内存不足，查看节点统计：

```bash
curl -s -u elastic:changeme "http://localhost:9200/_nodes/stats/jvm" | grep -E '"heap_used_percent"'
```

示例输出：

```text
"heap_used_percent": 92
```

根因确认：from=99980 时，协调节点需要从每个分片取 100000 条，5 个分片共 500000 条，排序后丢弃 499980 条。

**错误尝试：** 一开始想调大 `max_result_window` 到 200000，让深分页能跑。

```bash
curl -s -u elastic:changeme -X PUT "http://localhost:9200/ad_click/_settings" \
  -H 'Content-Type: application/json' \
  -d '{"index.max_result_window": 200000}'
```

结果第 5000 页能返回了，但 took 涨到 4.1 秒，堆内存峰值 95%，问题更严重。

> 先疑刷新未生效，
> 再疑排序无索引。
> 查到最后是内存，
> 深翻丢弃是根因。

# 07、优化

```text
V1：from/size 深分页 3.2 秒
证据：协调节点排序 50 万条，丢弃 49.998 万条
V2：search_after + PIT，目标 500ms 内
```

改用 search_after，核心是稳定排序键。

排序键必须唯一，否则翻页会漏数据或重复。

这里用 click_time + _id 双字段排序，_id 保证唯一性。

先创建 PIT：

```bash
curl -s -u elastic:changeme -X POST "http://localhost:9200/ad_click/_pit?keep_alive=5m" \
  -H 'Content-Type: application/json'
```

示例输出：

```text
{"id": "46uAQwFhZGJfY2xpY2sWNmhBUVNkYlZTeS1UY0dHcXlBQUFBQUFBQUFBFlY0cG9Fb1dUcU9pN0NXV1VhQ2x3AAAAAAAAAAABFkF6Y0pVZ2VuU0tpYl9XeHdfd0dWZw=="}
```

V2 查询代码：

```java
public SearchAfterPage<AdClick> pageBySearchAfter(String pitId, Object[] searchAfter, int size) {
    List<FieldSortBuilder> sorts = List.of(
            new FieldSortBuilder("click_time").order(SortOrder.DESC),
            new FieldSortBuilder("_id").order(SortOrder.DESC)
    );
    NativeQueryBuilder builder = NativeQuery.builder()
            .withQuery(QueryBuilders.matchAllQuery())
            .withSort(sorts)
            .withPageable(PageRequest.of(0, size));
    if (searchAfter != null) {
        builder.withSearchAfter(searchAfter);
    }
    Query query = builder.build();
    SearchHits<AdClick> hits = operations.search(query, AdClick.class);
    List<AdClick> content = hits.getSearchHits().stream()
            .map(SearchHit::getContent).toList();
    Object[] nextSort = hits.getSearchHits().isEmpty() ? null
            : hits.getSearchHits().get(hits.getSearchHits().size() - 1).getSortValues().toArray();
    return new SearchAfterPage<>(content, nextSort);
}
```

验证第 1 页：

```bash
curl -s -u elastic:changeme "http://localhost:9200/_search" \
  -H 'Content-Type: application/json' \
  -d '{"size":20,"pit":{"id":"46uAQ...","keep_alive":"5m"},"sort":[{"click_time":"desc"},{"_id":"desc"}]}'
```

示例输出：

```text
{
  "took": 15,
  "hits": { "hits": [ ... 20 条 ... ] },
  "pit_id": "46uAQ..."
}
```

取最后一条 sort 值作为 search_after，验证第 5000 页：

```bash
curl -s -u elastic:changeme "http://localhost:9200/_search" \
  -H 'Content-Type: application/json' \
  -d '{"size":20,"pit":{"id":"46uAQ...","keep_alive":"5m"},"sort":[{"click_time":"desc"},{"_id":"desc"}],"search_after":["2025-01-01T00:00:00Z","user_12345"]}'
```

示例输出：

```text
{
  "took": 42,
  "hits": { "hits": [ ... 20 条 ... ] }
}
```

V2 结论：第 5000 页从 3.2 秒降到 42ms，堆内存峰值从 92% 降到 38%。

> 游标替代偏移量，
> 排序键要唯一。
> 快照锁定时间点，
> 深翻从此不费力。

# 08、演进

```text
V2：search_after + PIT
能力：深分页稳定、翻页一致性、内存可控
遗留：不支持跳页、PIT 需管理生命周期
```

用 V1 同一组请求前后对比：

```text
第 1 页：V1 18ms → V2 15ms
第 5000 页：V1 3200ms → V2 42ms
堆内存峰值：V1 92% → V2 38%
```

收益：深分页延迟稳定在 50ms 以内，翻页期间视图一致。

代价：不能跳页，产品层要改成“上一页/下一页”交互。

PIT 需要定期续期或关闭，否则占用资源。

```bash
curl -s -u elastic:changeme -X DELETE "http://localhost:9200/_pit" \
  -H 'Content-Type: application/json' \
  -d '{"id":"46uAQ..."}'
```

适用条件：Feed 流、无限滚动、深页列表。

遗留问题：总条数仍需单独 count 查询，且 count 本身也有成本。

> 深翻稳定五十毫秒，
> 内存峰值降一半。
> 跳页功能要舍弃，
> 快照生命周期管。

# 09、洞见

```text
从现象到判断：分页是产品概念，游标是引擎策略
```

## 反直觉判断：search_after 不是分页，是游标
```text
产品分页：第 N 页、共 M 页、可跳页
引擎游标：只有“下一页”、无总数承诺
```
很多人以为 search_after 是 from/size 的替代品，其实它改变了语义。

产品层如果坚持显示“共 5000 页”，就要单独 count，成本另算。

## 反直觉判断：Scroll 不适合用户点击“下一页”
```text
Scroll：创建快照→顺序拉取→用完关闭
用户翻页：随时可能停、可能跳、可能开新标签
```
Scroll 的快照上下文会一直占用堆内存，用户翻到第 3 页就走了，scroll_id 却还活着。

大量废弃 scroll_id 会拖垮节点，这就是为什么官方建议用 search_after 替代 Scroll 做深分页。

## 判断：排序键唯一性是 search_after 的生命线
```text
排序键不唯一：翻页漏数据、重复数据
排序键唯一：游标定位精确
```
用 click_time 单字段排序时，同一毫秒的文档顺序不稳定。

必须追加 _id 或另一个唯一字段作为最终排序键。

## 判断：PIT 是 search_after 的可选增强，不是必选项
```text
无 PIT：翻页期间写入会导致结果跳动
有 PIT：翻页期间视图冻结
```
如果索引写入频繁，用户翻页时新文档插入会打乱排序。

PIT 冻结视图，代价是额外资源，按需开启。

> 产品要页码，
> 引擎要游标。
> 快照保一致，
> 扫描为批量。

# 10、系统落地

```text
入口：广告后台查询接口
服务：分页策略选择器
本模块：from/size + search_after + PIT + Scroll
存储：Elasticsearch ad_click 索引
未实现：Scroll 全量导出接口
```

原来系统只有 from/size 分页，深翻必崩。

本篇增加 search_after + PIT 深分页能力，深翻延迟从秒级降到毫秒级。

现在系统能支持：浅分页跳页、深分页顺序翻页、翻页期间视图一致。

下一篇缺 Scroll 全量导出：运营需要导出 20 万条明细，目前只能一页页翻。

官方文档：https://www.elastic.co/docs

> 入口还是那个口，
> 策略选择在里头。
> 浅深快慢各有路，
> 导出还差 Scroll 舟。

# 11、小结

```text
三问三答
```

为什么深分页会越来越慢？

因为 from/size 每次都要从每个分片取 from+size 条，排序后丢弃前 from 条，丢弃成本随页数线性增长。

普通用户点击“下一页”，该选 search_after 还是 Scroll？

选 search_after。Scroll 是批量扫描工具，快照上下文占用堆内存，用户随时停翻会造成资源浪费。

如果选错，会出现什么后果？

用 Scroll 做用户翻页，大量废弃 scroll_id 堆积，查询节点堆内存耗尽，整个集群查询变慢甚至 OOM。

当前状态：V2 已上线，深分页 P99 稳定在 50ms 以内，堆内存峰值下降 54 个百分点。

> 深翻慢在丢弃，
> 游标快在顺序。
> 快照保一致性，
> 扫描留给导出。

# 12、作业

```text
理解→实战→排障→架构判断
```

## 理解题：为什么 from/size 深分页的成本会随页数线性增长？
因为协调节点需要从每个分片取 from+size 条文档，汇总排序后丢弃前 from 条。页数越深，from 越大，每个分片要取的文档数越多，协调节点排序和丢弃的成本就越高。

## 实战题：用 search_after 实现一个无限滚动接口，要求排序键唯一，并验证翻页无重复无遗漏。
排序键用 click_time DESC + _id DESC。

第一页不带 search_after，取最后一条的 sortValues 作为下一页的 search_after。

连续翻 100 页，把 _id 收集到 Set，验证 Set 大小等于 2000，且无重复。

## 排障题：search_after 翻页时发现第 3 页和第 4 页有重复数据，可能是什么原因？
最可能是排序键不唯一。如果只用 click_time 排序，同一毫秒的文档顺序不稳定，翻页时游标定位漂移。修复方法是追加 _id 作为最终排序键。

## 架构判断题：产品经理要求“支持跳转到第 500 页”，同时要求延迟小于 100ms，这个需求能实现吗？
不能同时满足。跳页需要 from/size，深分页延迟必然超过 100ms。search_after 延迟低但不支持跳页。需要和产品沟通，要么放弃跳页，要么接受深页延迟，要么用预计算缓存。

> 理解深翻成本源，
> 实战游标写一遍。
> 排障先查排序键，
> 架构判断要提前。

# 13、升华

```text
工程结论：分页是产品概念，游标是引擎策略
```

有依据的结论：from/size 适合浅分页和跳页，search_after 适合深分页和无限滚动，PIT 适合需要一致性快照的翻页，Scroll 适合全量导出。

四种模式不是互斥的，而是按访问模式分层选择。

产品层关心页码，引擎层关心游标，两层解耦才能既满足体验又保住性能。

下一篇将实现 Scroll 全量导出接口，解决运营导出 20 万条明细的需求。

> 浅深快慢各有路，
> 产品引擎两层分。
> 莫把工具当概念，
> 数据访问要用心。

**系列项目：** 广告后台查询与导出系统

**已完成：** from/size 浅分页、search_after + PIT 深分页

**本篇：** 四种分页/遍历模式选型与 search_after 实战

**下一篇：** Scroll 全量导出接口与流式处理

以下按示例系列设计，已有能力为示例前置能力，待与前文核对。

很多团队把 Elasticsearch 当 MySQL 用，分页一律 from/size。前几页没问题，一旦用户点到第 50 页，延迟从几十毫秒涨到几秒。

《Spring ES实战》第8招 分页别只会Page

从浅分页到深分页，再到 Feed 无限滚动与数据导出，用四种模式打通 ES 数据访问策略。

架构师

数据库

后端

开发工具

Elasticsearch分页方案深度解析，对比from/size、search_after、PIT与Scroll四种模式原理与适用场景。通过20万条数据实测验证：深分页使用from/size导致延迟飙升至3.2秒，改用search_after+PIT后降至42ms，堆内存峰值从92%降至38%。核心结论：from/size适合浅分页跳页，search_after适合深分页顺序翻页，Scroll用于全量导出，强调排序键唯一性对游标稳定性的关键作用。

Elasticsearch 

代码解释

MySQL

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Elasticsearch分页方案深度解析，对比from/size、search_after、PIT与Scroll四种模式原理与适用场景。通过20万条数据实测验证：深分页使用from/size导致延迟飙升至3.2秒，改用search_after+PIT后降至42ms，堆内存峰值从92%降至38%。核心结论：from/s...

《Spring ES实战》第8招 分页别只会Page-腾讯云开发者社区-腾讯云

《Spring ES实战》第8招分页别只会Page

《Spring ES实战》第8招分页别只会Page

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring ES实战》第8招 分页别只会Page

《Spring ES实战》第8招 分页别只会Page

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring ES实战》第8招分页别只会Page

《Spring ES实战》第8招分页别只会Page