es大页读取 - 技术栈

问题

在 Elasticsearch 中处理大数据集的分页查询（通常称为"大页查询"或"深度分页"）时，需要特别谨慎，因为不当的操作可能会对集群性能产生显著影响，Elasticsearch 提供了几种不同的方案，每种都有其适用的场景和注意事项。

为了让你能快速了解这几种核心方案的特点，我准备了一个对比表格：

名称	原理	场景	优点	缺点与注意
From/Size (浅分页）	类似 SQL 的 LIMIT offset, size。每个分片返回 from+size 条数据，协调节点汇总排序后返回指定范围。	浅页跳页查询（通常建议在 10,000 条数据以内）。	使用简单直观支持随机跳页。	深度分页时性能差，默认有 index.max_result_window 限制（10,000条）
Scroll (游标查询)	创建搜索上下文快照，每次基于 scroll_id 获取下一批结果。	深度遍历大量数据（如数据导出离线处理）。	适合获取大量数据	不适用于实时查询（数据是快照）；消耗资源且需手动清理；不支持跳页
Search After (查找后)	基于上一页最后一条结果的排序值进行查询。	实时深度分页（需连续翻页）。	实时性高；性能好于 From/Size 和 Scroll	不支持随机跳页；需要唯一且稳定的排序字段

如何选择分页方案

选择哪种方案，主要取决于你的具体需求：

如果你需要进行深度分页（超过10,000条数据），Search After 通常是进行实时查询的首选。它有效地避免了 From/Size 的性能瓶颈和 Scroll 的非实时性问题。
如果你的场景是数据导出、全量索引或离线分析，需要顺序遍历大量数据而不关心数据的实时变更，那么 Scroll 查询更为合适。
切记，常规的 From/Size 分页仅适用于浅分页（如前几百页）的场景。强行修改 max_result_window 来获取更深的数据，虽然技术上可行，但会给集群带来巨大的性能和稳定性风险。

核心方案使用指南

Search After (推荐用于实时深度分页)

首次查询，需要设置一个唯一的、稳定的排序字段组合（例如时间戳加上文档ID）

go 复制代码

GET /my_index/_search
{
  "size": 10,
  "sort": [
    {"timestamp": "desc"},
    {"_id": "asc"}
  ],
  "query": {
    "match_all": {}
  }
}

后续查询：使用上一次查询结果中最后一条文档的 sort 值作为 search_after 参数。

go 复制代码

GET /my_index/_search
{
  "size": 10,
  "sort": [
    {"timestamp": "desc"},
    {"_id": "asc"}
  ],
  "search_after": [1643012560000, "abc123"],
  "query": {
    "match_all": {}
  }
}

Scroll (适用于大数据量导出)

初始化滚动查询：指定 scroll 参数来设置搜索上下文的存活时间

go 复制代码

GET /my_index/_search?scroll=5m
{
  "size": 100,
  "query": {
    "match_all": {}
  }
}

获取后续结果：使用返回的 _scroll_id 来请求下一批结果

go 复制代码

GET /_search/scroll
{
  "scroll": "5m",
  "scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAJZ9Fnk1d......"
}

清理滚动上下文：使用完毕后，务必手动删除 scroll_id 以释放资源

go 复制代码

DELETE _search/scroll/DnF1ZXJ5VGhlbkZldGNo.....

调整 From/Size 限制 (谨慎使用)

如果确实需要临时突破 From/Size 的默认限制，可以修改索引设置，但请充分评估风险

go 复制代码

PUT /my_index/_settings
{
  "index.max_result_window": 50000
}