Elasticsearch分页不同方式汇总（案例举例）

 工作中用到了，经过实践探索，总结下来备忘。解决问题第一，只有干货。

如有帮到你，欢迎点赞收藏哦！

目录

问题产生背景

方式

---

问题产生背景

从es拉取数据时，因为数据量过大，导致查询出来不是想要的所有数据。

查询语法中如果不指定size则返回10条记录；指定size后获取的最高数据量是65536，超过65536条就会报错：

如果数据量远远大于65536呢？只查询65536条数据的话显然不是全额数据量，这里就需要采用分页了。

这里我们不考虑65535是怎么配置的，需不需要改配置，我们从使用方的角度来解决这件事。

方式

1，基于from + size ，该策略最大查询10000条数据，上限太低，可用场景太少，不能满足；

2，游标，实时滚动，前一次查询的结果会返回一个唯一的字符串，下次查询带上这个字符串进行下一页的查询；

3，scroll分页，快照，对实时性要求不高，但查询效率高。

首先我们可以看看响应包格式，查询的核心返回数据都是在hits这个数组中，该数组的长度就是本次请求数据量的实际长度：

方式1

第一种方式很简单，请求时携带from和size。from即查询的起始位置，size即从起始位置开始的记录数，类似于offset、limit：

    "from": 0, 
    "size" : 2,

如果想一次查2条，那么请求第二页时，就成了

    "from": 2, 
    "size" : 4,

方式2

首次请求携带sort字段，指定返回按哪个字段排序

, 
  "sort": [
    {
      "timestamp": "desc"
    }

请求后，拿到本次请求返回包--hits数组的最后一个返回值，记住其中的sort中的内容，这里我只指定了一个字段所以返回的sort中只有一个值，如图：

首次请求返回的数据量=65536时，把返回的sort值塞在第二次请求中，第二次及以后的请求中都需要带上search_after字段，如图：

继续进行第二次请求看看还有多少数据，以此类推，直到某次请求<65536时这次访问结束，多次请求返回的数据量叠加在一起就是需要的实际数据量了。

方式3

基于scroll分页，和第二种用法类似，请求URL需要携带参数?scroll=5m，首次请求后记住返回的_scroll_id字段值塞进下次的请求中。5m是快照过期时间，即es把本次快照的结果缓存起来的有效时间，值自定。首次请求如下：

往后的请求只需携带scroll、scroll_id这两个参数，查到的结果就是本页想要的结果，以此类推再记住这次请求返回的_scroll_id值...，第二次请求如下：

要查的数据量大于65536时，如果哪次请求的hits长度已经<65536了，那么数据已经获取完成了，叠加所有请求返回的数据即可。注意URL哈，后面的请求和首次有不一样哦！