标签：
昨天我在上班，正字开心的撸着代码，欸！手机突然响了，按下接听键，立刻听到那边哔哩吧啦的一串猛说。。。
我以前一个同事打过来的，这家伙刚从技术转做需求….技术是个菜鸟，具体的内容是这样的，那个谁啊，我这边现在有个需求，你看看从技术角度来讲难不难，是不是几条关联查询就能搞定了啊？
我这边有个站，客户说需要一个搜索功能，但他的搜索的要求不高，不像电商搜索那么变态，只需要大概只有50个类型，比如型号啊颜色啊名称啊，这种类型，我本来的设计是，页面上列出这50个类型，然后用户选择后，再输入相应的东西去点搜索，但是客户说这些太多，用户使用起来不方便，你说怎么解决啊，我本来以为几条sql就搞定了，就接下这个需求了……
然后bulabulabula逼逼了一大顿，我在电话这边一阵“呵呵”….忍不住大骂“你丫傻逼啊50个类型还他妈不多？”可能分贝有点高边上的同时都差异的看着我…
虽然我从事工作时间也不长，这块确实也没做过，不过思路还是有的，讲到搜索无非就是我们经常讲的“全文搜索”，什么叫全文搜索呢…顾名思义嘛，是吧，就是从一大篇文章中进行搜索。
其实我最先想到的一个比较糙的方案，我问他这50个类型匹配的内容本身存不存在什么规则呢？比如型号的话可能是由英文字母和数字组成的，具有一定的规则性，如果能把这50个类型的规则定义出来，然后写成正则表达式，然后根据用户的搜索，去匹配我们的正则，匹配上的用相应的类型和输入的内容去做like查询。。。
但是一想到like的效率问题，我就问了问他数据量….他没跟我具体说，然后又回到全文搜索的概念上了，他问我什么事全文搜索。
我就根据自己的理解来说一下，比如当前这个需求，我们可以在这个比如说商品吧，上来扩展出来一个字段，这个字段干什么呢？就用来存我这50个类型对应这个商品的内容。
举个例子：商品冰箱—>名称：小鸭冰箱，颜色：银色，型号：xykf1326
OK，那么我们冗余出来的这个字段假设是keysearch吧，那他的内容就应该是“小鸭冰箱银色xykf1326”
写到这里原来有困惑的小伙伴应该懂了吧，客户输入内容点搜索按钮的时候，执行的操作无非就是：
select * from item where keysearch like ‘%小鸭冰箱%’
这就是俗称的全文检索…..
当然了我这里就是说了一个概念….而且是我自己理解的概念，到实际处理上肯定不能这么马虎，比如用户输入一个“银色小鸭”….结果在上面的设计中就查不到了，这里还需要设计到一些分词手段，首先keysearch字段中存的内容就不可能这么简单，肯定有各种组合…这里不详细说这个了。
上述只是讲了全文搜索在数据库中的应用方式，但我们实际到大数据量的项目中这样搞肯定就不行，那么就要引入一个技术
solr技术，他是一个企业级的搜索应用服务器，可以将我们上面的数据库表中的数据刷到solr中，我们可以像查询表一样在solr中查询我们需要的数据，他可以返回给我们多种格式的数据类型，比如json/xml等格式，大家可以自己去了解下。
在solr中我们使用模糊查询效率跟数据库可完全不是一个量级的，我曾经单独研究过一点solr的皮毛，也做过测试，300万数据在solr中使用模糊查询各种查，都可以在1秒之内轻松返回。
ok，没错我跟那个哥们瞎比比了半天，直到旁边的同事都嫌我烦了….
后来挂了电话，他qq上跟我说…你第一个方案我们这边的技术还挺接受的，后面一个他们就不高兴做了….当然他指的是solr…因为他那边的人都不懂。
我当时就乐了，不高兴做？这群哥们也是醉了…太叼了…
我这朋友也挺奇怪的，有技术问题不找自己公司的技术商量，还tm打电话找我…他跟我说他刚进公司跟那群搞技术的还不熟，担心准备不充分说不出个所以然来再被他们忽悠遭鄙视，这才把主意打到我这里来。
注意：以上内容仅供参考….如有错误请大神们指条明路….另外非常希望有过相关经验的大神留下点经验心得~~
标签：
原文地址：http://blog.csdn.net/sun5769675/article/details/50437123
