1.传统的from + size
from + size must be less than or equal to: [10000] but was [58000]
搜索请求一次请求最大量为[10000]。我们的请求量已经超标，因此报错，异常信息提示我们请求大数据量的情况下使用Scroll API。
2. 使用Scroll API 请求
from/size
from 偏移，默认为0
size 返回的结果数，默认为10
在数据量不大的情况下我们一般会使用from/size，而在深度分页的情况下效率极低，该命令会把from+size条记录全部加在到内存中，对结果返回前进行全局排序，然后丢弃掉范围外的结果，并且每次执行都会重复这样的操作，运行速度极慢而且往往还会造成es内存不足而挂掉。
理解深度分页为什么慢
让我们假设在一个有5个主分片的索引中搜索。当我们请求结果的第一页（结果1到10）时，每个分片产生自己最顶端10个结果然后返回它们给请求节点(requesting node)，它再排序这所有的50个结果以选出顶端的10个结果。
现在假设我们请求第1000页——结果10001到10010。工作方式都相同，不同的是每个分片都必须产生顶端的10010个结果。然后请求节点排序这50050个结果并丢弃50040个！
在分布式系统中，排序结果的花费随着分页的深入而成倍增长。
from + size must be less than or equal to: [10000] but was [58000]
搜索请求一次请求最大量为[10000]。我们的请求量已经超标，因此报错，异常信息提示我们请求大数据量的情况下使用Scroll API。
2. 使用Scroll API 请求
from/size
from 偏移，默认为0
size 返回的结果数，默认为10
在数据量不大的情况下我们一般会使用from/size，而在深度分页的情况下效率极低，该命令会把from+size条记录全部加在到内存中，对结果返回前进行全局排序，然后丢弃掉范围外的结果，并且每次执行都会重复这样的操作，运行速度极慢而且往往还会造成es内存不足而挂掉。
理解深度分页为什么慢
让我们假设在一个有5个主分片的索引中搜索。当我们请求结果的第一页（结果1到10）时，每个分片产生自己最顶端10个结果然后返回它们给请求节点(requesting node)，它再排序这所有的50个结果以选出顶端的10个结果。
现在假设我们请求第1000页——结果10001到10010。工作方式都相同，不同的是每个分片都必须产生顶端的10010个结果。然后请求节点排序这50050个结果并丢弃50040个！
在分布式系统中，排序结果的花费随着分页的深入而成倍增长。
![[阴险]](http://img.t.sinajs.cn/t4/appstyle/expression/ext/normal/6d/yx_thumb.gif "[阴险]")
