1、问题现象描述

Result window is too large, from + size must be less than or equal to [10000] but was [xxxxx].

2、错误的解决方案

2.1 使用max_result_window的错误解决方案

网上你能搜到的大部分解决方法都是让你把max_result_window参数阈值调大。

具体执行代码为（注意：以下为错误解决方案，正解在文末）：

• 基于特定索引生效：

PUT <index_name>/_settings
{
  "index.max_result_window": <number>
}

• 基于全局生效配置：

PUT _all/_settings
{
  "index.max_result_window": <number>
}

2.2 官方对max_result_window参数的解释

没错，这的确能解决眼前问题，但是会带来严重的后果，最常见的就是后期频繁的 OOM，而且很难发现原因。

看一下官方对该参数的解释：

网上任何让你无脑增加参数值的做法都是非常不负责任的，相当于用dú品帮你治病，虽然眼前让你神清气爽，但是完全不顾及后果。

2.3 官方推荐的解决方案

官方文档：https://www.elastic.co/guide/en/elasticsearch/reference/8.3/paginate-search-results.html#search-after

下面我来把这个问题的正确答案详细解释一下。

3、问题原理剖析

正常情况下ES的分页代码如实下面这样的：

GET order_2290w/_search
{
  "from": 0,
  "size": 5
}

输出结果如下图：

很好理解，即查询第一页的5条数据。图中数字2即返回的五条文档数据。但是如果我们查询的数据页数特别大，达到什么程度呢？当from + size大于10000的时候，就会出现问题，如下图报错信息所示：

报错信息的解释为当前查询的结果超过了10000的最大值。那么疑问就来了，明明只查询了5条数据，为什么它计算最大值要加上我from的数量呢？而且Elasticsearch不是号称PB及数据秒级查询，几十亿的数据都没问题，怎么还限制最大查询前10000条数据呢？这里有一个字很关键：“前”，前10000条意味着什么？意味着数据肯定是按照某种顺序排列的，ES中如果不人工指定排序字段，那么最终结果将按照相关度评分排序。

4、关于max_result_window参数的正确理解

4.1 max_result_window参数的具体含义

max_result_window是分页返回的最大数值，默认值为10000。max_result_window本身是对JVM的一种保护机制，通过设定一个合理的阈值，避免初学者分页查询时由于单页数据过大而导致OOM。

在很多业务场景中经常需要查询10000条以后的数据，当遇到不能查询10000条以后的数据的问题之后，网上的很多答案会告诉你可以通过放开这个参数的限制，将其配置为100万，甚至1000万就行。

但是如果仅仅放开这个参数就行，那么这个参数限制的意义有何在呢？如果你不知道这个参数的意义，很可能导致的后果就是频繁的发生OOM而且很难找到原因

4.2 如果正确设置max_result_window参数

那么这个参数就完全不能动吗？当然不是，设置一个合理的参数阈值是需要通过你的各项指标参数来衡量确定的，比如你用户量、数据量、物理内存的大小、分片的数量等等。通过监控数据和分析各项指标从而确定一个最佳值，并非越大越好。

建议如果你不是对 ES 有足够的了解和使用经验，不要轻易修改max_result_window参数的阈值！

5、底层原理详解及正确的解决方案

正确的解决方法：使用 Search after

关于max_result_window的深层次原理，及 Search after 的使用方法