######1.现象 出现此错误的原因，是由于 es 的分页机制导致的。
我们都知道一般这种大量数据的分页需求，是很难高效地去跳页查找的。原因在于查询的时候，不管是
MySQL还是es，都是只知道起点而不知道有多少页的。要想知道有多少页，每页是哪几条数据，就得把
在这页之前的数据全部过一遍。
所以一般指定页码去跳页查询这类需求，在我们数据量起来的时候这样的需求是很吃资源（内存+CPU）的。
我们可以尝试转化这类需求，转化成提供一个【下一页】的查询方式。
如果我们确实需要比如指定 1-10万页之间指定页码去查询的需求，在这个 es 的问题中根据官方建议，深度查找可以通过修改 es 的默认配置来扩充。但是官方建议也是不要超过 5万条的查询范围，否则性能无法保证，甚至影响服务器正常运行。
curl -XPUT "http://{HOST_IP}:9200/{你的es索引名}/_settings" -d '{ "index" : { "max_result_window" : 最大条数例如100000 } }' -H "Content-Type: application/json"
2.es官方的原话如下：
“Depending on the size of your documents, the number of shards, and the hardware you are using, paging 10,000 to 50,000 results (1,000 to 5,000 pages) deep should be perfectly doable. But with big-enough from values, the sorting process can become very heavy indeed, using vast amounts of CPU, memory, and bandwidth. For this reason, we strongly advise against deep paging.”
翻译过来如下：根据文档大小，分片数量以及你所使用的硬件，分页的目标数据量在一万到五万个结果应该是完全可行的。 但是从性价比上来看，使用大量的CPU，内存和带宽，分页过程确实会变得非常费时。 所以我们强烈建议不要进行深度分页。
目前面对这种跳页的需求暂时没有想到更好的处理办法，后面有思路了再来补充完善吧。。