使用Search After时如何计算当前页码？ElasticSearch分页难题

针对你遇到的超10000条数据分页、无法使用from/size且不愿修改max_result_window的问题，以下是两种可行的官方推荐方案，结合你的date降序、id降序排序需求实现：

1. Search After + Point in Time（PIT）：支持页码导航的最优方案 #

这是官方推荐的深分页方案，既能保证数据一致性，也能实现类似传统分页的导航逻辑，同时无需修改集群配置。

具体实现流程： #

• 创建PIT快照：为查询创建一个时间点快照，避免分页过程中数据新增/删除导致结果偏移

  POST /你的索引名/_pit?keep_alive=5m
  

  响应会返回一个id，后续所有分页请求都需要携带这个PIT ID。

• 第一页查询：获取初始数据，同时记录总数据量和最后一条数据的排序字段值

  GET /_search
  {
    "size": 每页数据量,
    "query": { "你的查询条件": {} },
    "sort": [
      { "date": "desc" },
      { "id": "desc" }
    ],
    "pit": {
      "id": "第一步获取的PIT ID",
      "keep_alive": "5m"
    },
    "track_total_hits": true
  }
  

  • 从hits.total.value拿到总数据量，除以每页数量得到总页数
  • 提取最后一条结果的sort数组（比如["2024-05-20T12:00:00Z", "1001"]），作为下一页的search_after参数

• 后续分页查询：使用search_after基于上一页的最后一条数据定位

  GET /_search
  {
    "size": 每页数据量,
    "query": { "你的查询条件": {} },
    "sort": [
      { "date": "desc" },
      { "id": "desc" }
    ],
    "pit": {
      "id": "PIT ID",
      "keep_alive": "5m"
    },
    "search_after": ["2024-05-20T12:00:00Z", "1001"]
  }
  

• 清理PIT资源：分页结束后，手动删除PIT以释放集群资源

  DELETE /_pit
  {
    "id": "PIT ID"
  }
  

当前页码计算： #

在客户端维护一个页码计数器：初始查询对应第1页，每执行一次下一页请求就将页码加1，结合之前计算的总页数，即可明确当前所在页码。注意PIT的keep_alive时间要足够覆盖整个分页操作周期，避免中途失效。

2. Scroll API：适合批量导出，不支持任意页码跳转 #

Scroll API更适合批量导出数据的场景，它通过游标单向滚动获取数据，但无法直接跳转到指定页码，仅适合不需要页码导航的需求。

具体实现流程： #

• 初始查询生成游标

  GET /你的索引名/_search?scroll=5m
  {
    "size": 每页数据量,
    "query": { "你的查询条件": {} },
    "sort": [
      { "date": "desc" },
      { "id": "desc" }
    ],
    "track_total_hits": true
  }
  

  响应返回_scroll_id和第一页数据。

• 滚动获取后续数据

  GET /_search/scroll
  {
    "scroll": "5m",
    "scroll_id": "上一步的_scroll_id"
  }
  

• 清理游标：完成后删除scroll释放资源

  DELETE /_search/scroll
  {
    "scroll_id": "目标_scroll_id"
  }
  

补充说明 #

如果需要更严格的排序唯一性（避免极端情况下date和id重复的场景），可以在排序条件中加入文档的_seq_no（索引内部的序列号），修改后的排序规则为：

"sort": [
  { "date": "desc" },
  { "id": "desc" },
  { "_seq_no": "desc" }
]

这不会影响原有排序逻辑，仅作为兜底的唯一排序键。

内容的提问来源于stack exchange，提问作者phuc16102001