Elasticsearch 的深度分页问题，本质上是 from + size 查询方式在处理海量数据时，系统资源消耗会随分页深度线性甚至指数级增长。这主要体现在协调节点需要从所有分片拉取并排序远超所需的数据，导致协调节点内存压力大，甚至引发内存溢出（OOM）。
Elasticsearch 默认设置了 max_result_window 为 10,000，就是为了防止随意调整导致集群不稳定。
核心原因：为什么 from + size 不适用于深分页？
简单来说，from + size 查询为了返回第 1000 页的 10 条数据，需要先"吃力不讨好"地收集、排序并丢弃掉前 9990 条数据，这在分布式系统中开销巨大。
- 海量数据传输 ：假设查询
from=10000, size=10，且有 5 个分片，每个分片需要将自己前 10010 条数据发送给协调节点。 - 高昂排序开销 ：协调节点需要对所有分片发来的总计 50050 条数据进行全局排序。
- 巨大的资源浪费：好不容易完成排序后，只保留 10 条数据返回，其余 50040 条全部被丢弃，内存和 CPU 被严重浪费。
主流解决方案：如何正确解决深度分页？
针对不同场景，Elasticsearch 提供了几种高效的替代方案：
| 方案 | 核心机制 | 适用场景 | 关键限制 |
|---|---|---|---|
| Search After | 基于上一页文档的排序值，像"书签"一样精准定位下一页起始点。 | 用户实时交互分页（如"加载更多"），需要看最新数据且性能稳定的场景。 | 不支持随机跳页，需顺序翻页。 |
| Scroll API | 首次查询时生成一份数据"快照"（Snapshot），之后通过游标（Scroll ID）批量获取。 | 非实时的大批量数据处理：数据导出、数据迁移、索引重建（Reindex）等后台任务。 | 数据不实时（基于快照）；会占用大量资源，用后必须手动清理。 |
| PIT + Search After | 先用 Point In Time API 锁定一个时间点的索引视图，再进行 Search After 查询。 | 分页期间索引有大量更新 ，但要求分页结果视图一致性的场景。 | 使用略复杂，需管理 PIT 的生命周期。 |
如何选择具体方案？
- 满足用户前台分页，并且能接受按序浏览（如无限滚动） ：首选 Search After。
- 在分页过程中，必须保证结果视图自始至终完全一致 ：采用 PIT + Search After 的组合方案。
- 需求是离线导出数亿条日志数据 ：使用 Scroll API 最省心。
- 想提高导出海量数据的效率 ：使用 Sliced Scroll，它支持并行拉取数据，速度更快。
- 业务中，用户几乎不会翻到很后面的页面：可考虑业务层面限制，比如最多只提供 100 页的展示。
最佳实践与优化思路
- 限制
max_result_window：生产环境保持默认值 10,000 是安全的选择。 - 确保排序字段的唯一性 ：使用
Search After时，必须保证排序值是全局唯一的，最佳实践是组合_id字段作为辅排序字段。 - 合理设置返回数据量 (
size)：不要贪多，设置一个合适的值有助于控制网络开销和内存消耗。 - 优化索引设计 ：对于按时间范围查询的场景，可以采用时间分区索引策略。
- 及时清理 Scroll 资源：务必及时清除不再使用的 Scroll ID，避免资源泄漏。
如果你能分享一下具体的业务场景（例如是"用户交互"还是"数据导出"），我可以帮你做更具体的方案选型～