排序处理：【sort与query同级别，是一个数组，里面可以有多个排序参数，参数以{"FIELD":{"order":"desc/asc"}}为格式】
GET /people/test/_search
{
  "query": {
    "match_all": {}
  }, 
  "sort": [
    {
      "age": {
        "order": "desc"
      }
    }
  ]
}

deep paging

对于分页和排序，需要共同面对一个问题：

• 首先，你要想到一个索引中的数据是散落在多个分片上的，你如何确定另一个分片上的数据与其他分片上的顺序问题？，比如可能A分片上的有数值为1和数值为3的数据,而B分片上有数值为2和数值为4的数据,所以B分片的部分数据与A分片数据的大小是不确定的。那么排序的时候怎么处理这些散落的数据呢？（就算是依据相对度来排序，这个时候散落的数据的相关度也是不太好确定的）

• 分页需要面对的问题也同样是因为数据散落的而不好排序的问题，因为分页也是要排序的，默认是按相关度排序。因为散落的数据的值的大小不确定，所以就需要把所有可能的数据取出来排完序再分页，这就会导致需要取出远远超出“页数”的数据来计算。

• 有两个primary shard（命名为A和B），现在要取第1000页的数据，假设每一页10条记录，那么理论上是只需要取第10000到第10010条记录出来即可。
• 但这时候我们并不知道A和B中的_score的大小如何，可能A中的最小的_score要比B中的最大的_score都要大，反过来也有可能，（所以我们并不能说仅仅从A和B中分别取10000到10010出来进行比较即可，我们需要对前面的数据都进行比较，以避免最小的_score都比另一个shard上的_score大的情况），为了确保数据的正确性，我们需要从A和B中都取出1到10010的数据来进行排序比较，然后再取出里面的10000到10010条。
• 所以，你看到了，我们只是为了拿十条数据，竟然要查10010数据出来。这就是deep paging了。

补充：

• 除了上述的内容，一个没讲的而且比较重要的内容应该是滚动查询，滚动查询有点类似分页查询，但它会提前准备好数据，我暂时没想好放在哪里讲合适，可能会在后面写，也有可能某一天补充在这里。

小节总结：

上面讲了怎么进行数据的分页获取和数据的排序，使用from和size分页，使用sort排序；还讲了一个如果查询时页数太深而可能导致的deep paging问题，问题的原因是多个分片上的数据大小不确定，不方便排序。