Elasticsearch深度分页性能优化：从原理到四种实战解决方案

1. 项目概述：当分页查询成为性能“黑洞”

在数据驱动的业务场景里，分页查询几乎是所有系统的标配功能。无论是后台管理系统的用户列表，还是电商网站的商品展示，用户早已习惯了“上一页/下一页”的操作。然而，当数据量从百万级跃升至亿级，一个看似简单的深度分页请求，就可能瞬间将你的Elasticsearch集群拖入泥潭，轻则查询超时，重则直接导致节点内存溢出（OOM）而宕机。这就是Elasticsearch深度分页问题的典型表现。

我遇到过不少团队，在业务初期数据量不大时，直接使用from和size参数进行分页，一切运行顺畅。但随着数据指数级增长，某天突然收到报警，发现某个查询耗时从几十毫秒飙升到几十秒，甚至彻底失败，追查下去，根源往往就是深度翻页。比如，用户想查询第10000页的数据（假设每页10条），使用from=99990, size=10。这个请求在ES内部的实际工作方式，远比你想象的要“笨重”得多。

简单来说，Elasticsearch的深度分页问题，本质上是其分布式检索模型与用户直观的“页码”概念之间的根本性冲突。理解这个冲突，并掌握几种核心的解决方案，是从业者构建稳健搜索服务的必修课。本文将彻底拆解这个问题背后的原理，并为你提供四种经过实战检验的解决方案，从适用场景、实现细节到避坑指南，一次性讲透。

2. 深度分页问题的根源：分布式系统的“一致性视图”代价

要解决问题，必须先理解问题为何产生。很多人知道深度分页慢，但未必清楚它到底慢在哪里。这需要我们从Elasticsearch的基本架构和查询流程说起。

2.1 传统from/size分页的工作原理

当你执行一个类似GET /my_index/_search?from=99990&size=10的查询时，Elasticsearch内部并不是直接去定位第99990条记录。其处理流程可以分解为以下几个步骤：

1. 查询阶段（Query Phase）：客户端请求发送到协调节点。协调节点将查询转发给索引的所有相关分片（主分片或副本分片）。每个分片在本地执行查询，各自独立地计算出满足条件的前from + size条数据的文档ID和排序值（如_score），然后返回给协调节点。注意，每个分片返回的是自己本地排名前(99990+10)=100000的结果，而不是全局的前100000。
2. 收集与排序阶段（Fetch Phase）：协调节点收集所有分片返回的结果。假设索引有5个主分片，那么协调节点将收到5 * 100000 = 500000条文档的元信息。它需要在内存中对这50万条结果进行全局排序，以找出真正全局排名在99990到100000之间的那10条文档。
3. 取回阶段：协调节点确定了最终的10条文档后，再根据其文档ID和所在分片，向对应的分片发送第二次请求，获取这10条文档的完整内容（_source），最后组装返回给客户端。

问题的核心暴露了：为了获取全局第99990到100000条数据，ES需要在协调节点内存里，对分片数 * (from + size)条数据进行排序。这个开销随着from值的增大而线性增长，消耗大量的CPU和堆内存。更致命的是，每个分片需要构建一个长度为from+size的优先级队列并维护它，这同样消耗分片节点上的内存。

2.2 深度分页带来的具体风险

基于上述原理，深度分页会引发三大风险：

1. 性能断崖式下跌：查询耗时与from值成正比。翻页越深，需要排序的中间结果集越庞大，响应时间从毫秒级增至秒级甚至分钟级。
2. 内存溢出风险：协调节点需要聚合和排序海量中间结果，极易撑爆JVM堆内存，导致节点崩溃。分片节点上的优先级队列也可能过大。
3. 结果不一致性：在分页过程中，如果索引有数据写入（新增、更新、删除），由于各分片执行查询的快照时间点可能有细微差异，可能导致后续页出现重复数据或丢失数据。例如，第一页查询后，一条数据被更新并排序位置后移，它可能既出现在第一页，又出现在第二页。

注意：Elasticsearch官方明确警示，from + size的默认限制是10000。这并不是一个硬性上限，你可以通过index.max_result_window设置调大它，但官方强烈不建议这么做，因为这相当于放大了上述风险，很可能导致集群不稳定。

所以，当业务提出“需要支持无限滚动或任意深度跳页”的需求时，我们必须清醒地认识到，沿用传统数据库的分页思维是行不通的，必须寻求更适合分布式搜索引擎的解决方案。

3. 解决方案一：Scroll API —— 一次性快照遍历

ScrollAPI的设计初衷并非为了分页，而是为了高效地导出大量数据或进行全量处理。但它提供了一种“游标”机制，恰好可以用来安全地遍历深度结果集。

3.1 原理与适用场景

Scroll查询会在初始查询时，为当前索引数据创建一个快照视图。这个快照在指定的“存活时间”内保持不变，无视期间的数据变更。然后，它返回一个_scroll_id，客户端通过反复使用这个_scroll_id来获取下一批结果，直到遍历完成。

它的核心价值在于：除了第一次查询，后续的每次“翻页”请求成本极低，因为ES不需要再像from/size那样重复进行全局排序，它只需要根据上次的位置继续向后获取即可。

最适合的场景：

• 大数据导出：需要将索引中所有符合条件的数据导出到文件或数据库。
• 后台全量处理：比如对全量数据重新计算标签、生成报表。
• 需要深度遍历，但不需要实时性的分页：例如，运营后台需要手动核查大量历史数据。

最不合适的场景：实时、高并发的用户界面分页。因为Scroll会占用大量的服务器资源来维护快照上下文，且生命周期较长，如果用于用户频繁翻页，会快速耗尽资源。

3.2 实操步骤与核心参数

假设我们需要导出所有“状态为活跃的用户”。

1. 初始化Scroll查询：

   POST /users/_search?scroll=5m { "size": 100, "query": { "term": { "status": "active" } }, "sort": ["_doc"] }

   • scroll=5m：设置Scroll上下文在服务器端的存活时间为5分钟。每次使用_scroll_id都会刷新这个时间。务必根据数据量大小合理设置，太短可能遍历不完，太长则占用资源。
   • size：指定每次返回的批次大小。这里设为100。
   • sort: ["_doc"]：这是一个关键优化。使用_doc排序（即文档的索引顺序）是最高效的，因为它避免了相关性算分（_score）的计算。如果业务必须按其他字段排序，性能会有所下降。

2. 获取结果及scroll_id： 上述请求的返回结果中，除了第一批数据，还会包含一个_scroll_id字段。保存这个值。

3. 遍历后续数据： 使用上一步得到的_scroll_id来获取下一批数据。

   POST /_search/scroll { "scroll": "5m", "scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAC...（很长的字符串）" }

   重复此步骤，直到返回的hits.hits数组为空。

4. 清理Scroll上下文（重要！）： 遍历完成后，必须主动释放资源。即使不手动清理，上下文在超时后也会自动释放，但主动清理是好习惯。

   DELETE /_search/scroll { "scroll_id": ["上述的_scroll_id"] }

3.3 注意事项与避坑指南

• 资源吸血鬼：每个Scroll上下文都会在ES集群中占用内存和文件句柄。高并发地创建大量Scroll上下文是致命的。务必在客户端逻辑中确保用完即焚，及时清理。
• 非实时性：这是快照，遍历期间的新增、更新、删除数据不会被包含在内。这对于需要实时性的业务是不可接受的。
• 不适合跳页：Scroll只能顺序遍历，无法直接跳到第N页。它是“游标”，不是“页码”。
• size不宜过大：虽然可以设置很大的size一次性拉取更多数据，但这会增加单次请求的网络传输压力和协调节点的内存压力。通常建议在100-1000之间权衡。

实操心得：我曾用Scroll实现过一个千万级用户数据的夜间批量打标任务。最初没有设置sort: ["_doc"]，并且scroll时间设了30分钟，结果任务运行缓慢且偶尔超时。后来改为_doc排序并将size从500调整为1000，同时严格控制Scroll上下文的创建和销毁，任务时间缩短了60%。关键在于，要把Scroll看作一个“批处理工具”，而不是“交互式查询工具”。

4. 解决方案二：Search After —— 实时游标分页

Search After是Elasticsearch为解决深度分页问题而提供的“官方推荐”方案，旨在克服Scroll API的实时性缺陷和资源占用问题。

4.1 原理与适用场景

Search After的思路是使用上一页结果中的排序值作为“游标”或“书签”，来获取下一页。它不维护一个服务端的快照上下文，因此没有Scroll那样的资源开销，并且能实时反映索引的变更。

工作原理：

1. 首次查询时，指定一个或多个具有唯一性或高度区分度的字段作为排序条件（例如_id或时间戳）。
2. 在返回的结果中，取出最后一条数据的排序值。
3. 下一次查询时，将这些排序值作为search_after参数传入，ES会定位到该位置之后的数据。

最适合的场景：

• 无限滚动（Infinite Scroll）：移动端或Web端常见的“上拉加载更多”。
• 需要实时性的深度分页：后台管理系统需要查看实时数据列表，并且可能翻很多页。
• 替代from/size进行深度查询。

4.2 实操步骤与排序技巧

假设我们有一个文章索引，需要按创建时间倒序分页，并且支持无限滚动。

1. 首次查询（第一页）：

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

   关键点：排序条件中，除了业务字段create_time，必须追加一个唯一字段（如_id）作为降级排序条件。这是因为create_time很可能不是唯一的（同一毫秒可能有多篇文章），如果没有唯一字段，当两篇文章create_time相同时，分页可能会丢失数据或出现重复。_id是唯一的，可以保证排序结果的确定性。

2. 处理结果并获取“游标”： 假设返回的最后一条数据是：

   { "_id": "article_123", "_source": {...}, "sort": [1640995200000, "article_123"] }

   注意结果中的sort数组，它包含了我们指定的排序字段的值。1640995200000是create_time的时间戳，"article_123"是_id。

3. 查询下一页（第二页）： 使用上一条结果的sort值作为search_after参数。

   GET /articles/_search { "size": 10, "query": { "match_all": {} }, "sort": [ {"create_time": "desc"}, {"_id": "asc"} ], "search_after": [1640995200000, "article_123"] }

   ES会找到create_time <= 1640995200000且_id > "article_123"（因为_id是asc）的所有文档，然后取前10条。这样就精准地定位到了下一页的起始位置。

4. 后续翻页：重复步骤2和3，每次都用当前页最后一条的sort值作为下一次的search_after。

4.3 注意事项与避坑指南

• 必须保证排序字段值的唯一性组合：这是最重要的原则。如果只用时间戳排序，在时间戳相同的情况下，翻页会混乱。_id是最可靠的保底字段。
• 不支持随机跳页：和Scroll一样，Search After只支持顺序遍历（下一页）。你无法直接跳到第50页，除非你保存了第49页最后一条的排序值。这意味着客户端需要维护这个“游标”状态。
• 查询条件必须一致：翻页过程中，query、sort、size必须保持不变，否则结果无法衔接。
• 数据变更的影响：在翻页过程中，如果数据发生变更（例如，一条数据的排序字段值被修改），它可能会在新的位置出现，从而导致重复或丢失。但由于每次查询都是实时的，这比Scroll的不变性更符合多数业务场景。

实操心得：在实现一个新闻Feed流时，我们采用了Search After。前端的典型模式是：首次加载后，将返回的sort值缓存在本地或服务端会话中。当用户滚动到底部时，携带这个sort值请求“下一页”。这里有一个坑：如果排序字段是“热度分”（一个动态计算的值），那么在两页请求的间隙，热度分可能变化，导致少量数据顺序微调，但用户体验上基本无感知。对于需要绝对顺序稳定的场景（如按ID分页），则要使用静态字段。

5. 解决方案三：折叠查询（Collapse）与去重后分页

有些深度分页的需求，源于数据本身存在大量重复或需要按某个维度聚合后展示。例如，一个电商搜索“手机”，结果中可能包含同一款手机的不同颜色、配置，用户希望先按商品SPU（标准产品单元）去重分页，点击后再看SKU（库存量单位）详情。这时，Collapse（折叠）功能就派上用场了。

5.1 原理与适用场景

Collapse允许你根据一个或多个字段对搜索结果进行折叠（去重），每个折叠组（即相同字段值的文档组）只返回排序最靠前的那一条文档。你还可以通过inner_hits获取该组内其他文档的信息。

它的价值在于：将海量的、重复的文档集合，压缩成一个更具代表性的视图进行分页，极大地减少了需要处理的数据量，从而间接解决了深度分页的性能问题。因为分页是基于折叠后的结果集进行的。

最适合的场景：

• 商品列表去重展示：按商品ID折叠，展示最热门或最新的一个SKU。
• 论坛/社区主题帖列表：按主题帖ID折叠，只展示最新回复或最热门的回复。
• 日志分析中按错误类型聚合：按错误码折叠，查看每种错误的最新一条实例。

5.2 实操步骤与inner_hits使用

假设有一个商品SKU索引，字段包括spu_id（商品ID）、sku_id（规格ID）、price、sales（销量）等。我们需要按SPU去重，并展示每个SPU中销量最高的那个SKU，然后对这个列表进行分页。

1. 基础折叠查询：

   GET /skus/_search { "from": 0, "size": 10, "query": { "match_all": {} }, "collapse": { "field": "spu_id" }, "sort": [ {"sales": "desc"} ] }

   这个查询会：

   • 将所有spu_id相同的文档归为一组。
   • 在每个组内，按sales降序排序。
   • 只返回每个组里销量最高的那条文档。
   • 最后，对这个“折叠后”的文档列表进行分页（from=0, size=10）。

   注意：这里我们仍然使用了from/size，但因为数据先被折叠了，假设10亿个SKU属于100万个SPU，那么实际参与排序分页的文档量从10亿降到了100万，性能提升巨大。但from值很大时，依然有深度分页问题，只是阈值被大大推后了。

2. 结合Search After进行深度折叠分页： 为了彻底解决深度分页，可以将Collapse与Search After结合。

   GET /skus/_search { "size": 10, "query": { "match_all": {} }, "collapse": { "field": "spu_id" }, "sort": [ {"sales": "desc"}, {"spu_id": "asc"} ] }

   首次查询后，获取最后一条结果的sort值（例如[1500, "spu_100"]，1500是销量，spu_100是SPU_ID）。下一页查询时，使用search_after：

   GET /skus/_search { "size": 10, "query": { "match_all": {} }, "collapse": { "field": "spu_id" }, "sort": [ {"sales": "desc"}, {"spu_id": "asc"} ], "search_after": [1500, "spu_100"] }

3. 使用inner_hits获取组内详情： 折叠后，如果我们还想知道每个SPU下有哪些SKU，可以使用inner_hits。

   "collapse": { "field": "spu_id", "inner_hits": { "name": "skus_in_spu", "size": 5, "sort": [{"price": "asc"}] } }

   在返回结果中，每个折叠后的文档会包含一个inner_hits对象，里面是这个SPU下按价格升序排列的前5个SKU详情。

5.3 注意事项与避坑指南

• 折叠字段的选择：折叠字段必须是单值字段（如keyword），且最好有较高的基数（不同值较多）。如果折叠字段值大量重复，折叠效果有限。
• 排序决定代表文档：每个折叠组返回哪条文档，完全由全局sort决定。确保你的排序逻辑符合业务“代表”的选取规则（如最新、最热、最便宜）。
• 性能考量：折叠操作本身有开销。inner_hits会显著增加响应大小和计算成本，需谨慎设置size。
• 结果数估算不准：使用折叠后，hits.total.value表示的是折叠前的总命中数，而不是折叠后的组数。获取准确的组数需要额外的聚合查询，成本较高。

实操心得：在一个电商搜索项目中，我们最初尝试直接用from/size对SKU分页，在深度翻页时性能极差。引入按spu_id折叠后，性能立竿见影。但遇到了新问题：用户有时想按“价格最低”的SKU作为SPU代表展示。这要求我们动态调整全局排序（例如sort: [{"price": "asc"}]），而inner_hits里可以再按销量排序展示其他SKU。这种“外层一个排序，内层另一个排序”的灵活性，很好地满足了复杂的产品需求。记住，collapse是一种用“业务逻辑”换取“性能提升”的典型方案。

6. 解决方案四：业务折衷与前端优化 —— 放弃“精准跳页”

很多时候，技术方案的瓶颈可以通过调整产品交互来巧妙规避。对于面向用户的搜索系统，“精准跳页到第10000页”本身可能就是一个伪需求。Google、百度等搜索引擎也早已放弃了传统的页码跳转。

6.1 原理与设计思路

这种方案的核心思想是：不对海量结果集进行全局的、精确的偏移量计算，而是通过更智能的筛选和排序，将用户可能感兴趣的结果提前，或者让用户通过更具体的条件来缩小结果集，从而避免深度翻页。

常见的设计模式：

1. “无限滚动” + “搜索条件优化”：

   • 交互：放弃页码，采用上拉加载更多（即Search After的完美前端搭档）。
   • 优化：提供强大的排序（按时间、热度、价格）和筛选器（分类、品牌、价格区间、标签）。引导用户通过筛选来将结果集从百万级减少到千级以内，然后再进行浏览。一个活跃的筛选器组合是避免深度分页的最佳手段。

2. “近似分页”与“游标缓存”：

   • 对于后台管理系统等确实需要跳页的场景，可以不完全放弃页码，但接受其“近似性”。
   • 例如，估算总条数（ES的track_total_hits设置为一个合理上限，如10000），然后使用Search After。当用户输入页码时，系统根据page * size估算出一个大概的search_after位置（可能需要一些预查询或近似计算），而不是精确跳转。并提示用户“当前为近似位置”。

3. “时间切片”分页：

   • 对于按时间序列的数据（日志、新闻、动态），分页完全可以被“按时间范围查询”替代。
   • 第一页：查询“今天”的数据。
   • 点击“加载更早”：查询“昨天”的数据。
   • 通过一个日期选择器，用户可以快速定位到任何时间段，这比翻成千上万页高效得多。

6.2 实操策略与前端配合

策略一：强化排序与筛选这是成本最低、效果最显著的方案。与产品经理紧密合作，分析用户真实的查询意图。

• 将“最相关”（综合相关性、销量、评分、上新时间）的结果排在前面。
• 暴露关键的、有区分度的筛选维度。例如，在商品搜索中，“品牌”、“价格区间”、“配送方式”的筛选效率远高于翻页。
• 技术实现：这需要你在ES的查询DSL上下功夫，设计合理的function_score查询来提升排序质量，并利用filter来高效处理筛选条件。

策略二：实现安全的游标分页（前端示例）前端需要配合Search After工作。

1. 首次搜索：请求参数不带search_after。
2. 接收结果：保存最后一条数据的sort值（例如，一个由时间戳和ID组成的数组）。
3. 加载更多：用户滚动到底部时，将保存的sort值作为search_after参数发起下一次请求。
4. 更新游标：用新结果集的最后一条sort值更新本地游标。
5. 关键点：游标状态可以保存在前端内存、URL哈希或服务端会话中。要处理用户中途修改搜索条件的情况——此时必须重置游标，发起一次全新的搜索。

策略三：限制最大查询窗口并友好提示这是一种防御性策略。在业务代码层或ES设置层，硬性限制from + size的最大值（例如5000）。当用户请求超出此范围时，不执行查询，而是返回友好提示：“您查询的数据过深，请尝试添加筛选条件或使用更具体的关键词缩小范围。” 这直接教育了用户，也保护了集群。

6.3 注意事项与避坑指南

• 产品共识是关键：技术方案变更必须获得产品和业务方的理解与支持。你需要用性能数据（如深度分页的响应时间曲线）和用户体验（如Google的案例）来说服他们。
• 前端状态管理：使用Search After时，前端需要妥善管理游标状态。在单页应用（SPA）中，要确保浏览器前进/后退操作不会破坏游标逻辑。
• 总条数的处理：Search After无法高效获取精确的总条数。对于“无限滚动”，可以不再显示总条数和总页数，或者显示一个估算值（“约10万+结果”）。对于需要精确总数的后台，可以单独用一个开了track_total_hits的count查询，但要明白这个查询本身可能很重。
• 排序字段的稳定性：用于Search After的排序字段组合必须是稳定的。如果业务上允许数据修改排序字段值（如更新商品价格），那么用户在翻页过程中可能会看到数据“跳动”。需要根据业务容忍度来评估。

实操心得：在我们的一次系统重构中，最大的挑战不是技术实现，而是改变固有的产品思维。我们通过A/B测试，将旧版（带页码）和新版（无限滚动+强化筛选）进行对比。数据显示，使用新版的用户，平均搜索点击率提升了15%，而平均翻页深度从3.5页下降到了1.8页。这说明，更好的排序和筛选，确实能让用户更快找到目标，从而根本不需要深度翻页。这个数据成为了我们推动方案落地的最有力武器。技术方案最终要服务于业务目标和用户体验，有时，改交互比改代码更有效。

7. 方案选型速查与决策指南

面对四种方案，如何选择？下表提供了一个快速决策参考：

决策流程建议：

1. 首先问业务：用户真的需要跳到第10000页吗？能否通过更好的排序、筛选、搜索建议来减少结果集？如果能，业务折衷方案是最优解。
2. 如果需要深度遍历：
   • 对实时性有要求（如用户操作） -> 选择Search After。
   • 对实时性无要求（如离线任务） -> 选择Scroll API，但务必注意资源管理和设置sort: ["_doc"]。
3. 如果数据需要按维度聚合展示（如商品按SPU去重） -> 选择Collapse，并可结合Search After应对深度。
4. 最后一道防线：对于任何方案，都应在业务层或网关层设置合理的分页深度上限和超时时间，防止恶意或异常的查询拖垮集群。

8. 常见问题与排查技巧实录

在实际开发和运维中，除了方案选型，还会遇到各种具体问题。这里记录几个典型案例和排查思路。

问题1：使用Search After翻页时，偶尔出现重复数据。

• 排查：首先检查排序条件。重复数据几乎总是因为排序字段组合不具备唯一性。例如，只按create_time排序，而同一毫秒内插入了多条数据。
• 解决：确保排序条件中至少包含一个唯一性字段（如_id）作为最后的降级排序。sort: [{"create_time": "desc"}, {"_id": "asc"}]。
• 更深层原因：在翻页间隙，如果文档的排序字段值被更新（例如，一条数据的评分被改变），它可能在新页面重新出现。这需要根据业务一致性要求来权衡。

问题2：Scroll查询运行一段时间后超时失败。

• 排查：
  1. 检查scroll参数设置的时间是否足够长以完成整个遍历。大数据集导出需要更长时间。
  2. 检查客户端逻辑，是否在每次滚动请求后都刷新了scroll_id？有时旧的scroll_id会失效。
  3. 使用_nodes/statsAPI 查看集群的“scroll上下文”数量是否过多，导致内存压力。
• 解决：
  1. 适当增加scroll时间（如从5m到30m），并在客户端逻辑中，每次收到响应后，用返回的新_scroll_id进行下一次请求。
  2. 为Scroll任务设置一个独立的、负载较低的客户端，并确保任务完成后调用清除API。
  3. 在ES配置中，可以设置search.max_open_scroll_context来限制全局Scroll上下文数量，防止滥用。

问题3：Collapse后，如何获取折叠字段（如SPU）下的文档总数？

• 挑战：hits.total反映的是折叠前的文档总数。要获取折叠后的组数，Collapse本身不提供。
• 解决方案：
  1. 近似值（高效）：使用cardinality聚合来估算折叠字段的唯一值数量。这对于分页导航栏显示“约XX条结果”通常足够。

     GET /skus/_search { "size": 0, "aggs": { "unique_spus": { "cardinality": { "field": "spu_id", "precision_threshold": 10000 } } } }

  2. 精确值（昂贵）：使用composite聚合或terms聚合（设置size为一个大数）来获取所有唯一的折叠键，然后统计数量。警告：这在大数据集上非常消耗资源，可能不适用于生产环境高频查询。

问题4：业务方坚持要提供“总页数”和“精确跳页”，怎么办？

• 沟通与教育：展示性能测试数据，说明深度跳页对集群稳定性的风险。举出主流互联网产品（搜索引擎、电商、社交平台）都已放弃该模式的例子。
• 提供替代方案：
  • “加载更多”模式：说明这是更流畅的移动端体验。
  • “时间轴”或“筛选器”导航：对于日志、新闻等，按时间或分类导航比页码更高效。
  • “近似跳页”：实现一个功能，允许输入页码，但实际使用Search After进行一个“最近似”的定位，并提示用户“已定位到附近位置”。这需要在业务层做一些额外的逻辑处理。
• 设定硬性限制：作为妥协，可以提供一个较大的但有限的分页窗口（比如最多500页），并与运维一起设定好监控，确保集群在极限情况下仍能承受。

一次线上事故复盘：我们曾有一个后台功能使用了简单的from/size分页，并默认track_total_hits为true。某天运营人员导出一个包含数千万条数据的报表，并请求了最后一页。这个查询试图在协调节点内存中计算和排序数千万条数据的总数以及偏移量，直接导致该节点OOM宕机，引发连锁反应。教训：对于任何面向内部或外部的分页接口，都必须有防御性设计：限制最大from+size，谨慎使用track_total_hits，对于导出类需求，强制走ScrollAPI 异步任务通道。