业务介绍
手机号模糊搜索对于用户来说是很常用的场景，比如要根据手机号搜索客户的相关订单、搜索客户的历史数据、搜索员工的相关操作记录等等。强制要求用户一定要输入完整的手机号不是合理，而且也很难用，包括我自己在内，记忆四位手机号和记忆完整手机号是感觉完全不同的。还有些场景手机号是要脱敏的，用户可能只能感知到后四位。
技术实现
假设，我们储存使用的是最常见的mysql，大家都知道如果是全模糊搜索%%是无法走索引的，性能会非常差，所以我之前设计过一种方案，手机号额外使用三个字段344进行存储。比如说普通用户表是以下存储方式。
| userId | mobile |
|---|---|
| 1 | 13500000005 |
| 2 | 13500000010 |
| 3 | 13500000012 |
手机号344是以下存储方式
| userId | mobile | head | mid | taill |
|---|---|---|---|---|
| 1 | 13500000005 | 135 | 0000 | 0005 |
| 2 | 13500000010 | 135 | 0000 | 0010 |
| 3 | 13500000012 | 135 | 0000 | 0012 |
因为大多数人的阅读方式还是344格式的，对head、mid、taill分别加索引后，同时要对用户的输入做query改写。
比如说传入4位数，就要查两次，mid一次，tail一次。
比如说传入的是8位数，那就进行分割，拿到后四位查一次，用mobile进行like。 select * from table where taill = ‘xxxx’ and mobile like ‘%xxxxxxxx%’
该种方式能有效走索引，不会引发全表扫描。
但是个人不是很建议使用，因为像用户这类信息基本上都有相应的ES存储，没必要在mysql上浪费额外的空间和索引。
最佳推荐使用（性能最强）
如果有ES索引的话，mobile字段用whitespace分词方式，写入文档的时候把手机号处理成135 0000 0005。
PS：ES自定义tokenizer很难满足我们这类场景，把手机号按照344分割，所以建议在写入的时候预处理，这样也能方便对不同国家的手机格式进行适配。
在查询的时候使用match_phrase就好了 ，要注意的是查询的时候同样要按照分词方式进行query改写，比如用户输入八位12344567查询要分割成1234 4567。
{"query" : {"bool": {"must": [{ "match_phrase": {"mobile": "1234 4567"}}]}}
}
当然为了更好的用户体验，也可以使用edge_ngram分词器，他会把手机号按照不同的步长进行切分（缺点是数据会膨胀很多，浪费空间），使用edge_ngram + ES方式已经能达成全模糊的查询效果了。
{"index": {"max_ngram_diff": 50},"analysis": {"analyzer": {"phone_analyzer": {"tokenizer": "ngram_tokenizer"}},"tokenizer": {"ngram_tokenizer": {"type": "ngram","min_gram": 3, "max_gram": 11 }}}
}
