MySQL全文索引问题

bryantly 发布于 2012/11/26 15:36
阅读 720
收藏 3
 mysql的全文索引效率怎么样 ?我 43w条数据建全文索引为什么查找时间在十几秒 。。。。
加载中
0
mark35
mark35
myisam支持FTS,innodb不支持
bryantly
bryantly
是Myisam 。。。表中存储的是中文内容已分词,关键字也是已分词的结果去匹配,最小索引长度为2,key_buffer_size 256 ,还是很慢。
0
无聊的人们啊
无聊的人们啊
mysql的全文索引对这样的查询语句才管用 like 'keywords%', 这样的'%keywords%'不会用全文索引。所以如果文章真的很长的话还是用lucene吧!
0
缪斯的情人
缪斯的情人

引用来自“阳光的毛毛”的答案

mysql的全文索引对这样的查询语句才管用 like 'keywords%', 这样的'%keywords%'不会用全文索引。所以如果文章真的很长的话还是用lucene吧!
他说的是mysql5.1后自带的full index,不是like,通过match匹配的。
缪斯的情人
缪斯的情人
回复 @bryanlty : 这个一直没实际用,一般还是大字段的用lucene,文档搜索无疑最快的
bryantly
bryantly
嗯,match()against()。我用的是布尔查询。 在网上看百万条数据效率不是很高的么,不知道为什么我这效率一直很低,开始在30秒左右,然后怎大Buffer_size 修改最小索引长度去停用词,不过还是要十几秒。我奇怪是就这么个效率还是没优化好 ?
0
无聊的人们啊
无聊的人们啊

引用来自“缪斯的情人”的答案

引用来自“阳光的毛毛”的答案

mysql的全文索引对这样的查询语句才管用 like 'keywords%', 这样的'%keywords%'不会用全文索引。所以如果文章真的很长的话还是用lucene吧!
他说的是mysql5.1后自带的full index,不是like,通过match匹配的。
看来我out了,我们用的是5.0几的呵呵
bryantly
bryantly
回复 @阳光的毛毛 : 这要是就这速度那也只能用lucene了,谢谢啦。
无聊的人们啊
无聊的人们啊
回复 @bryanlty : 用lucene试试啊,我们有个70万的表用的lucene,速度还可以,就是排序不好弄!
bryantly
bryantly
我的版本是5.1以后的,,数据好几十个G,所以肯定不敢考虑like了 。。。
0
sidneysu
sidneysu

为什么不用搜索引擎?

sphinx很好用啊。

bryantly
bryantly
回复 @sidneysu : 嗯,了解了。谢谢。
sidneysu
sidneysu
回复 @bryanlty : sphinx最大的优点在于有单独的索引文件,搜索的时候完全不占用mysql的资源。不过关键还是看你们的业务类型,需求决定架构
bryantly
bryantly
看了下增量式的重建索引比较快是吧 ? 问下50G的数据中搜索大概要多久呢 ?
0
mark35
mark35
mysql的FTS没用过。pgsql的FTS非常强悍,我把dz7.2的数据库换成了pgsql,对主题标题做了GIN FTS,33W条记录,输入语句搜索,也不过几十毫秒的查询开销。你这个太离谱了。
mark35
mark35
回复 @bryanlty : 主要是mysql没这能力。你看楼下宏哥的测试结果
bryantly
bryantly
应该是字段内容太大,那表有大概四十来个G,索引有差不多2G ,幸幸苦苦十几个小时建的索引 。。。。
0
宏哥
宏哥

引用来自“mark35”的答案

mysql的FTS没用过。pgsql的FTS非常强悍,我把dz7.2的数据库换成了pgsql,对主题标题做了GIN FTS,33W条记录,输入语句搜索,也不过几十毫秒的查询开销。你这个太离谱了。

http://www.oschina.net/question/96003_19020?sort=time

300万记录的索引, 对产品全名进行搜索.

在Dell 630上的512M的虚拟机上跑的结果.

mark35
mark35
就想到你这帖呢~
返回顶部
顶部