MySQL 的 like %关键字怎么优化？

昨天刚好看到 match()against 你可以去看看? 我也不是很懂，看见代码里有人这么写的，去搜了下，说是比like好

5.5以后支持了FullText Search

看你数据有多大的量，量不大，like就足够了,如果很大量就不能单纯依靠数据库,要用搜索引擎技术，先对内容做分词处理,建立反向索引,存到数据库.这会占用大量的空间,但查询速度和精度可以大大提高. 计算机永远是时间换空间，空间换时间的游戏

sphinx

@happywowwow
@mengzhuo
@em70
你们说的都是全文检索吧，
问题是建立的全文检索索引后，我理解只能匹配整词的输入条件，但是对于想用‘%ord'搜索到’Word‘的情况能match against到吗？

@em70 量大约是10w到100w记录级别，我理解全表扫面已经不可接受了。

@shyrock 难道oracle对于通配符在前的like能利用索引？

或许你们可以考虑单独用 ElasticSearch 做一个搜索的 service：

http://www.elasticsearch.org/

数据量大的花使用全文检索系统代替like

我知道我下面说的会被人喷，但是我还是要说：

就10万100万的数据，如果是考虑性能的话，根本不用 sphinx/elasticsearch 这种 full-text search engine。尽量让数据保持热度就可以了。

如果用了 sphinx/elasticsearch，还需要重新考虑各种过滤。

@love 据说可以加反向索引来解决，这个链接提到了，但是语焉不详： http://www.kuqin.com/database/20120207/317909.html
我又搜到另外一篇，比较靠谱，是建立function index + reverse的方式：
http://jeffkemponoracle.com/2008/01/17/like-with-wildcard-at-start-can-use-an-index/

@Livid 看了一下，elasticsearch是基于lucene的吧，实际上我们的系统中已经基于lucene搭了个全文检索。但是不能支持非整词匹配的模糊查询是个问题。

@davepkxxx 同上，全文检索无法完全覆盖需求。模糊查询是问题。

@qsun 100w级别的数据，保持热度的意思是全部放到内存中吗？我不清楚缓存中100w级别的全表扫描是什么性能。

@shyrock 你用的中文词库不支持自己增加词组？

@shyrock 啊，想到问题在哪里了，上一句话当我没说。

@shyrock 被检索字段数据量有多少,如果只是255以内,几十万的记录like问题应该也不大,服务器内存大点就OK了,100万以上,还是考虑反向索引吧,like不适合

@shyrock 100万全表ssd 上cluster index扫描大约10秒内

@shyrock 反向索引的意思是,把一段文本里的每个词都与原文建立对应关系,也就是说,一段文字有100个单词,那么需要创建100条记录,搜索的时候不搜索原文,在这100个记录里面查找,有匹配就说明原文里有这个单词,这100个记录建立索引查找就很快

谷歌百度他们,不光词做反向索引,还把多个连续词一起索引,甚至一句话也索引,一个网页可能建立几十万个反向索引,索引库可能几百亿,上千亿,实时搜索还是慢,这时他们还用了缓存技术,提前把可能搜到的词的搜索结果计算出来保存

@nilai 最近在比较sphinx和elasticsearch， 可以介绍下经验吗？