{“index”:{“_index”:“index_001”}}
{“id”:“3”,“name”:“lonely hello word wolf”,“result”:true}
{“index”:{“_index”:“index_001”}}
{“id”:“4”,“name”:“lonely”,“result”:false}
{“index”:{“_index”:“index_001”}}
{“id”:“5”,“name”:“wolf”,“result”:false}
基础查询
- 指定字段查询:
指定name字段查询
GET index_001/_search?q=name:wolf
- 使用默认字段查询:
GET index_001/_search?q=wolf&df=name
上面这两句话查询效果是一样的,均可以查询出 4
条数据,执行 profile
分析一下,确实只匹配了 name
一个字段:
- 泛查询(不指定任何字段)
GET index_001/_search?q=wolf
这条语句也是返回 4
条数据,但是这条语句和上面不同的是其没有通过 q
指定筛选字段,也没有通过 df
指定默认字段,所以会查询所有字段:
执行 profile
查询可以发现,这条语句会查询所有字段,而且有些类型不匹配则会报错,所以这种查询效率是很低的,生产环境中应该尽量避免。
- 指定
source
查询
再看下面的一个 source
查询例子:
GET index_001/_search?q=name:wolf&_source_includes=name,result&_source_excludes=result&timeout=1ms
这个例子中因为同时指定了 _source_excludes
和 _source_includes
,但是因为 _source_excludes
优先级比较高,故而最终只会返回 name
一个字段:
Term 查询
GET /index_001/_search?q=name:lonely wolf
这个查询会返回所有数据,因为默认情况下这个查询会使用 Term
查询,会查询 name
为 lonely
或者 wolf
的字段,而如果想把 lonely wolf
作为一个整体,则可以使用 Phrase
查询。
布尔操作
在上面 Term
查询中,我们发现当两个 Term
查询在一起,默认使用的是 or
的操作,而如果要使用 and
,则可以使用布尔操作。
布尔操作支持以下符号(必须大写):AND
,OR
,NOT
,&&
,||
,!
。如下例子则只会查询出 3
条数据。
GET /index_001/_search?q=name:lonely AND wolf
建议使用 () 来明确表示分组
GET /index_001/_search?q=name:(lonely AND wolf)
同时,布尔操作还支持一些高级查询,如:+
表示 must
,-
表示 must not
:
GET /index_001/_search?q=name:(+lonely -wolf)
这句话就只能查询出 id
为 4
的这条数据,name
含有 lonely
关键字且不含 wolf
关键字。
Phrase 查询
假如我们想把一句话当成一个整体来查询,则可以使用 Phrase
查询:
GET /index_001/_search?q=name:“lonely wolf”
这个时候就只会查询出一条数据。
通配符和正则查询
通配符查询中,?
表示 1
个字符,*
表示 0
或者多个字符。
没有符合条件的数据GET /index_001/_search?q=name:lone?# 1-4条数据都符合条件GET /index_001/_search?q=name:lone*
通配符查询是一种 like
查询,效率相对会比较低,所以一般也不建议使用。
此外,还可以通过正则表达式查询:
查询出 id 为 2 或 3 的数据GET /index_001/_search?q=id:(2|3)
近似查询
有些时候我们查百度的时候发现输错了字也能被查出来,这就是利用了近似查询,如下所示:
输错一个字符,查询不出结果GET /index_001/_search?q=name:loneyy# 允许一个字符错误,查询出 4 条数据GET /index_001/_search?q=name:loneyy~1# 允许两个字符错误,查询出 4 条数据GET /index_001/_search?q=name:loniyy~2
另外,针对上面的 Phrase
查询中,因为是把两个单词作为一个整体,那么也可以通过近似查询来设置允许中间有其他字符,如下:
GET /index_001/_search?q=name:“lonely wolf” ~1
这里表示允许 lonely
和 wolf
之间插入一个其他字符,所以可以查询出 2
条数据:
Request Body
查询是 Elasticsearch
中基于 json
格式提供的一种 DSL
语言(Query Domain Specific Language)。一般情况下,相比较于 URI Request
,虽然说 URI Query
也可以实现一定复杂程度的查询,但是一般情况下我们还是更推荐使用 Request Body
查询来实现更加复杂的一些组合查询。
通过 URI Search
中能实现的搜索方式,都可以通过 Request Body
来实现,下面就让我们一起来看看如何利用 Request Body
来进行搜索查询。
分页查询
Request Body
分页查询也是通过 from
和 size
来实现:
POST index_001/_search
{
“from”: 0,
“size”: 2
}
排序
排序通过 sort
来实现。注意,默认 text
类型不能排序,如果需要排序则使用 field.keyword
来查询:
POST index_001/_search
{
“sort”: [
{
“name.keyword”: {
“order”: “desc”
}
}
]
}
source 查询
同样的,Request Body Query
也可以使用 source
来指定返回字段,而且也支持通配符的方式来指定:
POST index_001/_search
{
“_source”: [“id”,“e”]
}
这时候查询会返回 id
,name
和 result
三个字段。
使用 match 查询
如果需要指定条件查询,在 Request Body
查询中则通过 match
来实现:
POST index_001/_search
{
“query”: {
“match”: {
“name”: “lonely wolf”
}
}
}
同样的,这个查询默认的也是“或”的关系,所以这里也是能将 5
条数据全部查询出来,如果要使用 AND
,则可以通过以下方式实现:
POST index_001/_search
{
“query”: {
“match”: {
“name”: {
“query”: “lonely wolf”,
“operator”: “and”
}
}
}
}
最后
无论是哪家公司,都很重视基础,大厂更加重视技术的深度和广度,面试是一个双向选择的过程,不要抱着畏惧的心态去面试,不利于自己的发挥。同时看中的应该不止薪资,还要看你是不是真的喜欢这家公司,是不是能真的得到锻炼。
针对以上面试技术点,我在这里也做一些分享,希望能更好的帮助到大家。
以通过以下方式实现:
POST index_001/_search
{
“query”: {
“match”: {
“name”: {
“query”: “lonely wolf”,
“operator”: “and”
}
}
}
}
最后
无论是哪家公司,都很重视基础,大厂更加重视技术的深度和广度,面试是一个双向选择的过程,不要抱着畏惧的心态去面试,不利于自己的发挥。同时看中的应该不止薪资,还要看你是不是真的喜欢这家公司,是不是能真的得到锻炼。
针对以上面试技术点,我在这里也做一些分享,希望能更好的帮助到大家。
[外链图片转存中…(img-1BTHOCrv-1714119852585)]
[外链图片转存中…(img-0LsLwWgK-1714119852586)]
[外链图片转存中…(img-eGPDNWOb-1714119852586)]