# Search After 原文链接 : [https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-search-after.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-search-after.html) 译文链接 : [http://www.apache.wiki/pages/editpage.action?pageId=4883118](http://www.apache.wiki/pages/editpage.action?pageId=488308) 贡献者 : [ping](/display/~wangyangting) 结果的分页可以通过使用 from 和 size 来完成，但是当达到深度分页时成本变得禁止。 index.max_result_window 默认为 10,000 是一种保护，搜索请求占用堆内存和时间与 from + size 成比例。 建议使用 Scroll api 进行高效的深层滚动，但滚动上下文是昂贵的，不建议将其用于实时用户请求。 search_after 参数通过提供活动光标来规避此问题。 这个想法是使用前一页的结果来帮助检索下一页。 假设检索第一页的查询如下所示： ``` GET twitter/tweet/_search { "size": 10, "query": { "match" : { "title" : "elasticsearch" } }, "sort": [ {"date": "asc"}, {"_uid": "desc"} ] } ``` Note: 每个文档具有一个唯一值的字段应用作排序规范的仲裁。 否则，具有相同排序值的文档的排序顺序将是未定义的。 建议的方法是使用字段 _uid，它确保每个文档包含一个唯一值。 上述请求的结果包括每个文档的排序值数组。 这些排序值可以与 search_after 参数结合使用，以便在结果列表中的任何文档之后“返回”结果。 例如，我们可以使用最后一个文档的排序值，并将其传递给search_after 以检索下一页结果： ``` GET twitter/tweet/_search { "size": 10, "query": { "match" : { "title" : "elasticsearch" } }, "search_after": [1463538857, "tweet#654323"], "sort": [ {"date": "asc"}, {"_uid": "desc"} ] } ``` Note: 当使用 search_after 时，参数 from 必须设置为 0（或 -1 ）。 search_after 不是一种自由地跳到随机页面的解决方案，而是一种并行地滚动许多查询的解决方案。 它非常类似于滚动 API，但不同的是，search_after 参数是无状态的，它总是解决对搜索器的最新版本。 因此，排序顺序可能会在步行期间更改，具体取决于您的索引的更新和删除。