took：执行整个搜索请求耗费了多少毫秒。

 

/_search

在所有的索引中搜索所有的类型

/gb/_search

在 gb 索引中搜索所有的类型

/gb,us/_search

在 gb 和 us 索引中搜索所有的文档

/g*,u*/_search

在任何以 g 或者 u 开头的索引中搜索所有的类型

/gb/user/_search

在 gb 索引中搜索 user 类型

/gb,us/user,tweet/_search

在 gb 和 us 索引中搜索 user 和 tweet 类型

/_all/user,tweet/_search

在所有的索引中搜索 user 和 tweet 类型

 

GET /_search?size=5

GET /_search?size=5&from=5

GET /_search?size=5&from=10

size

显示应该返回的结果数量，默认是 10

from

显示应该跳过的初始结果数量，默认是 0

理解为什么深度分页是有问题的，我们可以假设在一个有 5 个主分片的索引中搜索。 当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给 协调节点 ，协调节点对 50 个结果排序得到全部结果的前 10 个。现在假设我们请求第 1000 页--结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。 然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。可以看到，在分布式系统中，对结果排序的成本随分页的深度成指数上升。这就是 web 搜索引擎对任何查询都不要返回超过 1000 个结果的原因。

 

term是代表完全匹配，不进行分词器分析，文档中必须包含整个搜索的词汇

{    "query": {
            "term": {
                "area_code.keyword": "ALY"        }    }}

bool联合查询：must、must_not

must: 文档必须完全匹配条件

must_not: 文档必须不匹配条件

{    "query": {
            "bool": {
                "must": {
                    "term": {
                        "area_code.keyword": "ALY"                }            },            "must_not": [],            "should": []        }    }}