1、通配符搜索定义通配符搜索可以定义为支持通配符的模糊搜索。
与Mysql中的like模糊匹配相似。 如下所示。
wildcard在Elasticsearch中的使用方法如下。
通配符运算符是与一个或多个字符匹配的占位符。
通配符支持以下两种类型：
？支持一个字符的模糊匹配。 例如： Ma？ s只与Mars、Mass、Maps一致。
:支持0个以上的模糊匹配。 例如，Ma*s与Mars、Matches、Massachusetts等一致。
2、全球视野——wildcard搜索位置全球认知至关重要，搜索核心类型大致(非精确)，精确匹配搜索(Term-level queries )和基于分词的全文匹配搜索)全文本QQ
全文检索细分为：
精确的匹配搜索细分为：
也就是说，wildcard是与Term，Terms检索对等的检索。
3、通配符搜索应用场景应用于召回率要求较高的业务场景。
基于分词的全文检索，有可能明明存在却无法检索。 可能的原因如下。
原因1 )基础词典不完备；
原因2 :分词粒度不准确。
举个例子就明白了：
前述说明：
1、只不过是例子，不是针对具体的人。
2、Ik词典main.dic不是本地人，而是进行了网络词典的扩展，但词典中仍然没有“gxdgk”三个字。
3、如果本地测试结果与bzdbd不一致，很可能是因为词典不同。
puttest-004(mappings(: ) properties ) : ) title ) : ) type ) : ) text ) analyzer ) 3: ) itle ) type ) 60 ' keyword ' } } post test-004/_ bulk { ' index ' 3360 { ' index ' : { ' _ id ' :2 } { ' title ' 33602 {'tititititititiaty}我是' } post test-004/_ search { ' query ' : { ' match _ phrase ' 3360 { ' title ' 3360 ' GX DDD
理由是analyzer API可以说明一切。
post test-004/_ analyze { ' text ' : [ '京东英语官网承认gxdgk被逮捕一次的原因有xx '嫌疑]，' analyzer ' : ' ik _ max max
align: justify">面对如上召回情况，部分不追求精准率只追求召回率的业务场景，可能会需要文档_id = 1、2、3、4 全部都要召回。这时候，如果不改变分词的情况下，可能的解决方案之一就是：wildcard 检索实现。
POST test-004/_search{ "query": { "wildcard": { "title.keyword": "*gxdgk*" } }}如上的方式，文档1、2、3、4全部召回。
相当于在原有DSL的基础上，只改动检索方式和字段名称就搞定了产品经理的提高召回率的需求。
貌似，可以交差大吉了。实则，有非常大的隐患。
4、wildcard 可能的风险官方文档是这么说的：
中文含义是：避免以*或？开头的模式。这会增加查找匹配项所需的迭代次数并降低搜索性能。
wildcard 到底有多慢？如下示例可见一斑：
wildcard 检索字段指定的字符数多了以后，会报错如下：
在 wood 大叔 2017年的bzdbd中，曾经指出如下的核心点：
4.1 出现问题
用户输入的字符串长度没有做限制，导致首尾通配符中间可能是很长的一个字符串。后果就是对应的wildcard Query执行非常慢，非常消耗CPU。
4.2 根本原因
为了加速通配符和正则表达式的匹配速度，Lucene4.0开始会将输入的字符串模式构建成一个DFA (Deterministic Finite Automaton)，带有通配符的pattern构造出来的DFA可能会很复杂，开销很大。
源码及细节推荐阅读：
https://elasticsearch.cn/article/171
https://elasticsearch.cn/article/186
5、wildcard 实战中的悲剧如下，采用原汁原味的技术群交流内容，更具有说服力。
更能警示大家：慎用 Wildcard！
5.1 悲剧1：一味的满足产品经理的需求，wildcard 不考虑性能的乱用。 5.2 悲剧2：wildcard 参数传了一篇bzdbd进来，导致集群宕机！ 5.3 悲剧3：wildcard 搜索一百个汉字，导致CPU利用率 100%！注意是：不同100个字组合，一直搜。
5.4 悲剧4：客户现场演示，集群宕机！根因：bool 组合了近 100 组+ wildcard 不同关键词的检索。
6、wildcard 可能的替代方案在寻求解决方案的时候，我们要先问一下：为什么大家喜欢用 wildcard 实现模糊检索?
得到的答复往往是：顺手，类似Mysql like 查询，短、平、快的达到了产品经理的要求，满足了项目需求。
但，这忽略了性能问题以及可能带来的灾难后果。
所以，解决方案应该从根源上入手，以寻求彻底解决。
6.1 替代方案一：写入时分词优化，使用 Ngram 分词。更细粒度分词，更有利于数据的召回！
PUT test-005{ "settings": { "index.max_ngram_diff": 10, "analysis": { "analyzer": { "my_analyzer": { "tokenizer": "my_tokenizer" } }, "tokenizer": { "my_tokenizer": { "type": "ngram", "min_gram": 3, "max_gram": 10, "token_chars": [ "letter", "digit" ] } } } }, "mappings": { "properties": { "title": { "type": "text", "analyzer": "my_analyzer", "fields": { "keyword": { "type": "keyword" } } } } }}POST test-005/_bulk{"index":{"_id":1}}{"title":"英文官网承认gxdgk一度被捕的原因是涉嫌性侵"}{"index":{"_id":2}}{"title":"别提了朋友哥哥gxdgk窗事发了"}{"index":{"_id":3}}{"title":"gxdgk施效颦，没想到竟然收获了流量"}{"index":{"_id":4}}{"title":"gxdgk是谁？我不认识"}POST test-005/_search{ "query": { "match_phrase": { "title": "gxdgk" } }}Ngram 实现推荐：
Elasticsearch能检索出来，但不能正确高亮怎么办？
6.2 替代方案二：7.9 + 以上的版本，使用 wildcard 数据类型。wildcard 类型出现的目的：一方面避免了某些场景下分词查询不准确的问题，另一方面也解决了通配符和正则检索的效率问题。
注意：新上的数据类型 wildcard，而非 wildcard 检索。
使用方法参见：
https://www.elastic.co/guide/en/elasticsearch/reference/master/keyword.html#wildcard-field-type。
6.3 禁用方案：禁止使用wildcard 模糊检索特殊业务场景需要禁止：wildcard 检索。
实现如下：
PUT _cluster/settings{ "transient": { "search.allow_expensive_queries": false }}需要强调的是：
"search.allow_expensive_queries" 是 7.7+ 版本才有的功能，早期版本会报错。
7、小结由于技术惯性，我们习惯于相同或者相通技术的技术迁移，比如：mysql like 查询迁移到 Elasticsearch 中的 wildcard 模糊检索。但迁移的时候一定要注意：不同技术点的实现差异，同时要多关注技术点不能可能导致的性能问题。
即便 2017年 wood 大叔就发了两篇bzdbd让大家警惕 wildcard 模糊检索可能带来的性能问题。但四年后的今天，仍然很多公司的实战业务中还未考虑性能及后果的前提下，乐此不疲的用着 wildcard 检索！
所以，本文算是 wood 大叔的 wildcard 警示bzdbd接力，希望更多人看到。
参考：
https://t.zsxq.com/Y3zv7Eq
https://t.zsxq.com/bm62zZf
推荐：
如何系统的学习 Elasticsearch ？
从实战中来，到实战中去——Elasticsearch 技能更快提升方法论
重磅 | 死磕 Elasticsearch 方法论认知清单（2020年国庆更新版）
探究 | 明明存在，怎么搜索不出来呢？
中国最大的 Elastic 非官方公众号
更短时间更快习得更多干货
点击查看“阅读原文”，更短时间更快习得更多干货。和全球 1000 位+ Elastic 爱好者（含中国 50%+ Elastic 认证工程师）一起每日精进 ELK 技能！