7
回答
MySQL全文索引问题
终于搞明白,存储TCO原来是这样算的>>>   
 mysql的全文索引效率怎么样 ?我 43w条数据建全文索引为什么查找时间在十几秒 。。。。
举报
bryantly
发帖于5年前 7回/701阅
共有7个答案 最后回答: 5年前
myisam支持FTS,innodb不支持
--- 共有 1 条评论 ---
bryantly是Myisam 。。。表中存储的是中文内容已分词,关键字也是已分词的结果去匹配,最小索引长度为2,key_buffer_size 256 ,还是很慢。 5年前 回复
mysql的全文索引对这样的查询语句才管用 like 'keywords%', 这样的'%keywords%'不会用全文索引。所以如果文章真的很长的话还是用lucene吧!

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

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

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

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

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

为什么不用搜索引擎?

sphinx很好用啊。

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

引用来自“mark35”的答案

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

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

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

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

--- 共有 1 条评论 ---
mark35就想到你这帖呢~ 5年前 回复
顶部