[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AxL52JUV-1642658614346)(C:UsersAdministratorAppDataRoamingTyporatypora-user-imagesimage-20220118120951226.png)]
字段可自定义的参数 analyzer分词器 可定义一个细粒度分词器
boost字段评分权重
fielddata是否生成正向索引存储在内存中，只有生成才能对text字段聚合。但是全部内容加入内存。
ignore_abovekeyword字符串长度默认256
index决定字段是否可以被索引 如果是no，则无法通过检索查询到该字段；
norms是否参与打分
search_analyzer搜索分词器 可定义一个粗粒度的分词器搜索性能更高
normalizer参数用于自定义解析前（索引或者查询）的标准化配置。
doc_values默认是开启的，如果确定某个字段不需要排序或者不需要聚合，那么可以关闭 doc_values。
index_options控制索引时哪些信息被存储到倒排索引中（用在 text 字段中），有四种取值：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qG5hRAsx-1642658614347)(C:UsersAdministratorAppDataRoamingTyporatypora-user-imagesimage-20220118122306325.png)]
null_value让null值可以被索引和搜索 默认无法搜索
position_increment_gap被解析的 text 字段会将 term 的位置考虑进去，目的是为了支持近似查询和短语查询，当我们去索引一个含有多个值的 text 字段时，会在各个值之间添加一个假想的空间，将值隔开，这样就可以有效避免一些无意义的短语匹配，间隙大小通过 position_increment_gap 来控制，默认是 100。
PUT users
PUT users/_doc/1
{
"name":["zhang san","li si"]
}
GET users/_search
{
"query": {
"match_phrase": {
"name": {
"query": "sanli"
}
}
}
}
sanli` 搜索不到，因为两个短语之间有一个假想的空隙，为 100。
store默认情况下，字段会被索引，也可以搜索，但是不会存储，虽然不会被存储的，但是 _source 中有一个字段的备份。如果想将字段存储下来，可以通过配置 store 来实现。没必要存储
搜索 filter 不评分的must must 必须包含的 相当于and must_not 不包含 should 包含一个相当于or 1、match allPOST /_search
{
“query”: {
“match_all”: {}
}
}
2、matchPOST /_search
{
“query”: {
“match”: {
“name”: “亚马逊”
}
}
}
{
“query”: {
“multi_match”: {
“query”: “亚马逊”,
“fields”: [
“name”,
“city”
]
}
}
}
POST /company/employee/_search
{
“query”: {
“range”: {
“lastTrackTime”: {
“gte”: 1629777506000
}
}
}
}
//把这个字段当成exact value去查询(前提条件：手动创建mapping的时候需要指定no_analy不分词去建立索引，这样才可以用test hello在term搜到)
{
“query”: {
“bool”: {
“must”: [
{
“term”: {
“name.keyword”: “亚马逊”
}
}
],
“must_not”: [],
“should”: []
}
}
}
{
“query”: {
“bool”: {
“must”: [
{
“terms”: {
“name.keyword”: [
“亚马逊”,
“习惯”
]
}
}
],
“must_not”: [],
“should”: []
}
}
}
{
“query”: {
“match_phrase”: {
“name”: “亚马逊定制”
}
}
}
有容错率的like查询
{
“query”: {
“fuzzy”: {
“name.keyword”: “亚ma逊定制”
}
}
}
https://blog.csdn.net/laoyang360/article/details/115222329?utm_term=eswildcardQuery%E8%A6%81%E6%85%8E%E7%94%A8%E5%90%97&utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2allsobaiduweb~default-0-115222329&spm=3001.4430
避免以*或？开头的模式。这会增加查找匹配项所需的迭代次数并降低搜索性能。
like查询
{
“query”: {
“wildcard”: {
“name.keyword”: “定制”
}
}
}
如果一次性要查出来比如10万条数据，那么性能会很差，此时一般会采取用scoll滚动查询，一批一批的查，直到所有数据都查询完处理完
使用scoll滚动搜索，可以先搜索一批数据，然后下次再搜索一批数据，以此类推，直到搜索出全部的数据来
scoll搜索会在第一次搜索的时候，保存一个当时的视图快照，之后只会基于该旧的视图快照提供数据搜索，如果这个期间数据变更，是不会让用户看到的
采用基于_doc进行排序的方式，性能较高
每次发送scroll请求，我们还需要指定一个scoll参数，指定一个时间窗口，每次搜索请求只要在这个时间窗口内能完成就可以了
每次取3条
GET /test_index/test_type/_search?scroll=1m
{
“query”: {
“match_all”: {}
},
“sort”: [ “_doc” ],
“size”: 3
}
获得的结果会有一个scoll_id，下一次再发送scoll请求的时候，必须带上这个scoll_id
GET /_search/scroll
{
“scroll”: “1m”,
“scroll_id” : “1”
}
scoll，看起来挺像分页的，但是其实使用场景不一样。分页主要是用来一页一页搜索，给用户看的；scoll主要是用来一批一批检索数据，让系统进行处理的。
搜索性能优化建议：1.segment合并；索引节点粒度配置index.merge.policy.floor_segment=xx mb；segment默认最小值2M。SSD固态推荐100M
2.索引时不需要做打分的字段，关闭norms选项，减少倒排索引内存占用量。keyword会默认关闭
4.避免使用对象嵌套结构组建document，建议优化为一个扁平化结构，查询多个扁平化结构在内存做聚合关联；
5.设定字符串类型为不分词，可以用于字符串排序，但是比起数字排序会消耗cpu，搜索效率更低
term>=match>=math_phrase>fuzzy>wildcard
