如何解决 Elasticsearch 深度分页问题：Scroll 与 Search After 实战指南

在使用 Elasticsearch 进行数据查询时，我们通常使用 from 和 size 参数来实现分页。然而，当试图获取大量分页结果（例如，超过 10,000 条）时，这种方式会导致性能急剧下降，甚至抛出 Result window is too large 错误。这就是著名的“深度分页”问题。

本文将详细解析深度分页的原理，并提供两个高效且推荐的解决方案：Scroll API（滚动搜索）和 Search After。

深度分页的原理

Elasticsearch 是一个分布式系统。当你发起一个查询时，它会在所有相关分片上执行查询，然后将每个分片上的结果集（前 from + size 条数据）汇集到协调节点（Coordinating Node）。协调节点需要对这些结果进行全局排序，然后返回最终的 size 条记录。

如果 from 值非常大（比如 99,000），意味着每个分片都需要传输大量数据到协调节点，协调节点需要处理巨大的内存开销进行排序。为了保护集群稳定，ES 默认将 index.max_result_window 限制为 10,000。

方案一：Scroll API（滚动搜索）

Scroll API 提供了一种类似于数据库游标（Cursor）的机制，用于高效地获取大量数据（例如用于数据导出或重索引）。它会为查询建立一个时间点快照，后续的请求都是基于这个快照进行。这使得它非常适合数据全量导出的场景。

适用场景： 数据导出、数据迁移、一次性获取全部结果。

Scroll API 操作步骤

1. 首次请求：创建滚动上下文

在查询中添加 scroll 参数，指定上下文保持的有效期（例如 1m，即 1分钟）。

# 假设索引名为 products
POST /products/_search?scroll=1m
{
  "size": 1000,
  "query": {
    "match_all": {}
  }
}

返回结果示例： ES 返回第一批数据，同时返回一个关键的 _scroll_id。

{
  "_scroll_id": "DnF1ZXJ5VGhlbkZldGNo...",
  "hits": { ... }
}

2. 后续请求：使用 Scroll ID

将上一步获取的 _scroll_id 放入 /api/_search/scroll 接口中，不断请求，直到 hits.hits 为空为止。

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

3. 清除滚动上下文（重要）

滚动上下文会占用内存资源。任务完成后，必须手动清除 Scroll ID，即使它已经过期，这也是推荐的最佳实践。

DELETE /_search/scroll
{
  "scroll_id": [
    "DnF1ZXJ5VGhlbkZldGNo..."
  ]
}

注意： Scroll API 无法提供实时的、用户友好的分页（例如跳到第 50 页），因为它的结果集是固定的快照，并且请求之间无法回退或跳转。

方案二：Search After（实时游标分页）

Search After 是 Elasticsearch 官方推荐用于实时、深度分页的解决方案，它在 ES 5.x 版本后得到广泛应用。它通过指定上一页最后一条数据的排序值（sort value）作为“书签”，从而避免了 from 参数带来的性能开销。

适用场景： 实时用户分页、需要跳转或返回的分页操作。

Search After 操作步骤

1. 确保稳定的排序字段

search_after 必须依赖于一个稳定的、高区分度的排序（Sort）字段。最佳实践是至少使用两个字段进行排序，确保唯一性，通常以 _id 结尾。

2. 首次请求

像常规查询一样设置排序，但不使用 from。

POST /products/_search
{
  "size": 10,
  "query": {
    "match_all": {}
  },
  "sort": [
    { "price": "asc" },
    { "_id": "asc" } 
  ]
}

3. 获取 Search After 游标

从首次请求返回的 hits 数组中，找到最后一条记录，提取其 sort 数组的值。例如，如果最后一条记录的 sort 字段是 [150.0, “doc_id_99”]。

4. 后续请求：使用 Search After

将上一步获取的 sort 数组作为 search_after 的值，发送下一页的请求。

POST /products/_search
{
  "size": 10,
  "query": {
    "match_all": {}
  },
  "sort": [
    { "price": "asc" },
    { "_id": "asc" } 
  ],
  "search_after": [150.0, "doc_id_99"]
}

通过不断更新 search_after 的值，即可实现高效、无限的向后分页。

总结对比

对于绝大多数需要前端展示的实时分页需求，Search After 是更优、更高效的现代化解决方案。