优化 Elasticsearch 深度分页查询以避免性能冲击的核心方案是避免使用传统的 from+size 分页方式，尤其是在页码较深时。推荐采用 search_after 参数结合排序字段进行游标式分页，或者使用 scroll API 处理全量数据导出场景。此外，应合理设置 index.max_result_window 阈值，避免随意调大导致内存溢出。对于必须深度分页的场景，可考虑业务层优化，如限制最大翻页数或改用基于时间戳、ID 的范围查询，从而减少协调节点的数据聚合压力和内存消耗，确保集群稳定性。

Elasticsearch 深度分页问题的解决方案详解

1.1 什么是深度分页 查询耗时随页码深度 指数级增长; 内存与 cpu 资源消耗剧增; 超过阈值后直接被 es 拒绝。1.2 es 分页的底层执行机制 (from + size) es 是分布式搜索引擎，数据分布在多个分片上。标准分页 ( from + size ) 的执行流程如下：请求分发:协调节点将查询广播至所有分片; 分片执行:每个分片独立查询并返回 前 from + size 条记录 到内存; 结果汇总:协调节点收集所有分片的结果 (共 n× (from + size) 条); 二次排序 + 裁剪:全局排序后，仅保留 [from, from + size) 区间的数据返回。核心痛点:当 from = 10000 , size = 100 时，每个分片需加载 10100 条 数据，协调节点需对 所有分片的 10010 条 进行全局排序——最终却只返回 100 条!资源浪费极其严重。1.3 es 的保护机制:max_result_window 为防止 oom,es 默认设置：1 index.max_result_window = 10000 即 from + size≤ 10000 ,否则抛出异常。

Elasticsearch 深度分页性能优化：从 Scroll 到 Search After 的终极解决方案

1.1from + size 分页的致命缺陷 Elasticsearch 的分页查询：GET/products/_search{"from":10000,"size":10,"query":{"match_all":{}}} 一键获取完整项目代码 json 1 2 3 4 5 6 执行流程：查询阶段：每个分片需返回 10010 条数据 (假设有 5 个分片，总计 50050 条)。排序阶段：协调节点对所有分片返回的 50050 条数据进行全局排序。截断阶段：丢弃前 10000 条，仅返回剩余的 10 条。问题：内存爆炸：协调节点需缓存 (from + size) × 分片数条数据。CPU 计算瓶颈：排序海量数据导致高延迟。默认限制:index.max_result_window(通常设置为 10000)。1.2 实测性能对比

【Elasticsearch 进阶】之深度分页问题解决方案:From/Size、Scroll 与 Search After

1.1 为什么深度分页是分布式系统的"杀手级"问题？在分布式搜索领域，深度分页问题犹如一颗"定时炸弹"。根据我们的生产监控数据，深度分页查询引发的性能问题占所有查询性能问题的 40% 以上，而且这个比例随着数据量的增长呈指数级上升。让我们通过几个真实的系统崩溃案例来理解这个问题的严重性：1.1.1 从三个系统崩溃案例看深度分页的破坏力 案例一：电商平台大促期间的雪崩效应 某头部电商平台在双 11 期间遭遇的严重故障：时间：凌晨 2 点，流量高峰前 现象：商品搜索 API 响应时间从 50ms 激增到 30s+ 根本原因：爬虫程序使用 from=10000, size=50 抓取数据 影响链：单个深度分页查询消耗 1 个节点的全部 CPU 资源 查询队列堆积导致节点假死 其他正常查询被阻塞 整个集群响应时间飙升 最终触发服务雪崩 经济损失：故障持续 2 小时，损失订单约 5000 万元。

Elasticsearch - 闲聊 ElasticSearch 中的分页

Elasticsearch 深度分页问题的本质是在进行分页查询时，由于每个分片都需要生成大量的数据，并将这些数据发送到协调节点进行汇总，因此随着查询深度的增加，每个分片需要生成的数据条数也越来越大，从而导致查询效率降低。先说结论：在 Elasticsearch 中，也应该尽量避免使用深度分页。就如同在使用关系型数据库中，也是不能很好地解决深度分页的问题，因此要注意甚至明确禁止使用深度分页 https://www.elastic.co/guide/en/elasticsearch/reference/current/paginate-search-results.html 我们也看看 BBOSS 的深度分页解决方案 https://esdoc.bbossgroups.com/#/README from-size 在 ES 中，分页查询默认返回最顶端的 10 条匹配 hits。如果需要分页，需要使用 from 和 size 参数。from 参数定义了需要跳过的 hits 数，默认为 0; size 参数定义了需要返回的 hits 数目的最大值。

解决 Elasticsearch 分页查询性能瓶颈——从 10 分钟到秒级的优化实践

今天我们来聊聊球友提出的一个实际问题：ES 分页查询性能很差，使用 from/size 方式检索居然需要 10 分钟！这是一个非常典型的问题，尤其在大数据量、多索引场景下特别常见。我会从问题根源出发，逐步分析原因，并给出详细的优化方案和实现代码，希望能帮到遇到类似问题的朋友。球友的场景是这样的：他们通过 ES 的范围查询 (range query) 和排序 (sort) 从多个索引 (applcation*) 中分页检索数据，DSL 如下：curl -X POST"http://elasticsearch.elastic:9201/applcation*/_search"-H'Content-Type: application/json'-d' { "from": 0, "query": { "bool": { "filter": { "range": { "timestamp": { "from": "1743609600000", "include_lower": true, "include_upper": false, "to": "1744214400000" } } } } }, "size": 100, "sort": [ { "timestamp": { "missing": "_last", "order": "desc", "unmapped_type": "keyword" } }, { "_uuid_": { "missing": "_last", "order": "desc", "unmapped_type": "keyword" } } ] }' 一键获取完整项目代码 go 这个查询的目标很简单：从多个索引中查询时间戳在 1743609600000 到 1744214400000 之间 (约 7 天) 的记录。按 timestamp 和_uuid_降序排序。每次返回 100 条数据 (size=100),从第 0 条开始 (from=0)。但问题来了：查询耗时高达 10 分钟 (磁盘原因如下图说明，可以降到 2 分钟，但依然有很大优化空间)! ——铭毅补充说明:Elastic 集群最好独立部署！更夸张的是，命中数据量达到了 6 亿多条。这显然不是正常现象，我们得找到性能瓶颈。

FAQ

为什么 Elasticsearch 默认限制最大分页数为 10000？

为了防止内存溢出（OOM）和性能崩溃。深度分页会导致协调节点加载大量数据到内存进行排序，消耗巨大资源。

search_after 和 scroll 有什么区别？

search_after 适用于实时深分页，基于排序值游标；scroll 适用于全量数据导出，维护上下文快照，不适合实时查询。

能否直接调大 max_result_window 来解决深分页？

不推荐。这只是掩盖问题，分片仍需加载大量数据，协调节点排序压力剧增，极易触发 Full GC 或 OOM。