使用 from / size 分页

from - 表示起始位置，size - 表示每页数量；类似与 MySQL 的 limit + offset。
示例：

GET /_search
{
    "from" : 10, "size" : 10,
    "query" : {
        "term" : { "user" : "kimchy" }
    }
}

需要注意的是，from + size 不能超过10000，也就是说在前10000条之内，可以随意翻页，10000条之后就不行了。

实际上，通过设置 index.max_result_window 可以修改这个限制，但是不建议这么做，因为这种方式翻页越深效率越低。

原理：

Query阶段：

1. 当一个请求发送到某个ES节点时，该节点（Node1）会根据from和size，建立一个结果集窗口，窗口大小为from+size。假如from=10000,size=100，则窗口大小为10100。
2. 此节点将请求广播到其他相关节点上，从每个Shards中取Top 10100条的score和id。
3. 所有Shards获取的结果汇聚到Node1，假如有5个Shards，则一共会取到5 * 10100 = 50500条数据。
4. Node1进行归并排序，并选择Top 10100条，存入结果集窗口。

Fetch阶段：
根据Query阶段得到的排序结果，从 from 位置取 size 条数据，抓取文档详细内容返回。

从此过程中可以看出，翻页越靠后，需要参与排序的文档就越多，效率也就越低。所以，如果结果集很大，不建议用这种分页方式。

关于ES搜索请求过程，推荐一篇博文：https://blog.csdn.net/caipeichao2/article/details/46418413（其中query_and_fetch已经在对外接口中去掉了，所以只需了解query_then_fetch过程即可。）

使用 scroll 分页

使用scroll就像传统数据库中的游标一样，方式如下：

第一步

POST /twitter/_search?scroll=1m
{
    "size": 100,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    }
}

scroll=1m，表示“search context”存活时间1分钟。返回结果中会带有一个“_scroll_id”，这个值在后续的翻页过程中使用。

第二步

POST /_search/scroll
{
    "scroll" : "1m",
    "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="
}

不用指定index和type，也不用其他查询条件，只要把上一步的_scroll_id即可。

之后翻页一直如此，每次执行会自动滚动100条数据，直到返回的结果为空为止。

每次执行间隔不要超过1分钟，否则“search context”会释放掉。

第三步

DELETE /_search/scroll
{
    "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="
}

结果遍历完成后，删除scroll_id。这一步也可以不做，等1分钟后没有继续翻页请求，“search context”会自动释放掉，不过建议还是手动清除，节省资源。

优化：
如果目的是为了遍历所有结果，而不关心结果的顺序，那么可以按“_doc”排序来提高性能

POST /twitter/_search?scroll=1m
{
    "size": 100,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    },
    "sort": ["_doc"]
}

与 from/size 分页方式不同，使用 scroll 分页只能单向顺序翻页，不能随机翻页，适用于遍历结果集的场景。

scroll 翻页能够深度翻页，但是翻页期间需要维护“search context”，这是需要占用一定资源的。

所以对于用户高并发访问的场景，不推荐用这种方式，scroll 更适用于批处理类的后台任务。

使用 search after 分页

这种方式同样可以深度翻页，但是弥补了 scroll 方式的不足。其思想是：用前一次的查询结果作为下一次的查询条件。

示例：

首次查询

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

返回结果：

{
  "took" : 4379,
  "timed_out" : false,
  "_shards" : {
    "total" : 6,
    "successful" : 6,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 38213940,
    "max_score" : null,
    "hits" : [
      ...
      {
        "_index" : "user_model",
        "_type" : "_doc",
        "_id" : "00000f78f59644b1967783986c35496c",
        "_score" : null,
        "_source" : {
          ...
        },
        "sort" : [
          "00000f78f59644b1967783986c35496c"
        ]
      }
    ]
  }
}

后续查询

GET /user_model/_search
{
  "size": 10,
  "query": {"match_all": {}},
  "sort": [
    {"_id": "asc"}
  ],
  "search_after": ["00000f78f59644b1967783986c35496c"]
}

其中，search_after 为上次查询结果中最后一条记录的 sort 值。

总结：

1. 如果数据量小（10000条内），或者只关注结果集的TopN数据，可以使用from / size 分页，简单粗暴
2. 数据量大，深度翻页，后台批处理任务（数据迁移）之类的任务，使用 scroll 方式
3. 数据量大，深度翻页，用户实时、高并发查询需求，使用 search after 方式