在过去的项目上，总会遇到很多关于某个字段的模糊查询的需求，一般对于客户来说他会认为这个功能很简单，可能1天就可以完成这样一个功能，但是现实总是残酷的，往往这个功能是非常复杂的，今天我们就来聊聊一个关于姓名模糊搜索的功能，在不同的场景是如何决策的。
模糊搜索
模糊搜索主要用于用户搜索意图不明确或者数据较少想返回更多查询结果的场景,在说技术上如何实现这个模糊搜索的场景的时候，我想先聊聊现实生活中的场景
现实生活中的场景
我们在看书的时候，如果让我们在图1-1图片中找出产品两个字出现多少次，我们的大脑会把所有的字过一遍，然后得出一个结果，这个时间可能也就1分钟左右。
1-1.png
我们把场景更换一下，如果让我们在图1-2图片中找出产品"两个字出现的位置，我们的大脑依然会把所有的字过一遍，然后记录产品"这两个字出现的位置，然后得出一个结果，但是这个时间就不是一分钟就可以搞定的了，当然最终我们可以把这个结果集记录下来，下次如果还需要查产品"两个字，我们就不用重复上一步的步骤，而我们记录这个动作其实就是我们常说的缓存。
1-2.png
但是如果我们不想统计产品这两个字出现的次数，而是找出架构这个两个字出现多少次，我们该怎么办？看来只能在把书读一遍，然后记录下所有架构这个两个字出现的次数了。前面提到的记录次数这件事可以记录到一张纸上，但是我们总不能通过每次阅读一本书的方式来记录这个次数，或者查找某个词出现的地方，给我们所指引，这种效率太慢了，我们能不能把这些重要的信息提前写到书上，方便读者查询呢，事实上是可以的，就是我们常见的目录，附录，以及索引，如图1-3所示
1-3.png
而索引种类就很多了，我们在看不同的书有不同的索引，比较经典的书籍就是我们小时候学习的新华字典，他根据不同的场景，把索引创建了不同类型例如拼音(图1-4)，偏旁部首(图1-5）,笔画(图-1-6)索引等
1-4(拼音索引).png
1-5(偏旁部首索引).png
1-6(笔画索引).png
而这个神奇的设计就可以大大减少我们大脑通过全书查找某个关键信息的时间，所以理论上我们只要把所有的关键规则都变成索引页存在书的目录中，就可以很快查询到我们想要查询的信息，这一设计不仅深深的融入到我们现实的生活，而且也在软件系统上发光发热。
软件系统上中的场景
互联网也常常有模糊查找的需求，但是这个需求针对的是软件系统，而不再是现实生活中的书，比如在一个社区APP上按照昵称查找某个用户，在电商网站上搜索我们想要查找的商品(图2-1)，而这和我们现实生活中所查找的的算法是一摸一样的。
2-1.png
如图2-1所示我通过“sw”它匹配到的结果有“switch,三文鱼,丝袜，数位板..等，他们分别到了
1.拼音首字母索引:三文鱼(san wen yu),丝袜(si wa)
2.英文前缀索引: switch(switch)
而软件系统中的索引要远远多余上述两种，比如还有后缀搜索(是指搜索以指定后缀结尾的内容的检索),
单字或单字母搜索(模糊搜索支持单字或单字母搜索),短语查询(连续的字母和数字可以用短语查询)等，但这些无一例外都是建立在我们大脑中的逻辑认知所扩展出来了，也都逃脱不了现实场景，因为系统毕竟服务于人。软件系统如果没有上述的索引，实际上也是能工作的，这就回归到了文章开头所说的，一个关于姓名的搜索，计算机CPU扫描一本书的时间可是要比人脑快的不是一个数量级，就让他扫描不就行了嘛，个人理解这句话只能说对了一半，软件系统里的计算机的算力虽然很高，但是软件系统里的一本书(数据)可能要比现实生活中一本厚几万倍，这样的话计算机扫描一本书所消耗的时间也会增加，在加上同一时间里，如果每个客户有不同的搜索需求，就需要计算机同时对数据做扫描，这样即便是计算机也会很累的，这就会导致一些常见的问题出现，例如高峰时间段系统累坏了，垮掉了，或者响应很慢了(请求很久才返回查询结果)。当然如果软件系统中这本书如果很薄，那么对计算机而言就很简单，因为它可以飞快的扫描完得到结果。
既然结论说完了，咱们就看看不同的数据场景，都有哪些可以选型的技术，最终完成这样一个简单的搜索功能，是不是真的1天就可以完成。
数据库
如果说你开发一个姓名搜索的功能对应数据库是数据库例如mysql，那么恭喜你，对于模糊搜索的需求，你只能支持到前缀索引阶段，因为mysql原生只是支持到前缀索引,否则就要面临全表扫描的性能问题，或者应用相对复杂的全文索引，但是你要忍受查询精度问题，而这个问题往往是业务无法忍受的。如果数据量很小，那无所谓，我们就任由它全表扫描吧，1天完成这个功能还真的可以。
你可能会考虑使用文档类数据库例如mongodb，但是往往业务系统不会优先考虑使用文档数据库，而如果部分业务拿到文档里，也要考虑的成本，1天完成是有点难的
搜索引擎
在使用数据库搜索时，我们更多的是基于「精确匹配」的搜索，但是数据库毕竟只是个存储的工具，所以想追寻大量数据「相关性匹配」的查询速度，就必须有强大的文档索引支持，例如偏旁部首匹配，多音字匹配，语意匹配等就需要用到搜索引擎比如Elasticsearch，原理就是把数据库的相关信息传给搜索引擎，他会帮你把数据相关的索引全部创建好，这样就可以满足丰富的搜索需求，但这个成本是不可能1天完成的。
所以最终回到文章开头，如果业务人员说这个查询功能我必须要，是不是可以快速完成这个功能的时候，希望你可以根据现实情况考虑清楚后在答应他，否则你将会把自己陷入深渊。
