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": [] } } }