关于mysql的全文索引查询慢的问题?

pyruby 发布于 2013/05/23 14:06
阅读 946
收藏 1

现在业务上有如下需求:就是要判断用户注册的用户名是否重名,如果重名的话,要提示用户该用户名已经注册,现在遇到如下问题:

1:如果直接根据一个user_name=xxxxxxx条件去查mysql的话,会很慢,相当于全文索引了,mysql根本不行,要么就是给user_name建立索引,但是这样一来的话索引很大,这种方法个人感觉很不靠谱。。

2:直接去查全文搜索引擎sphinx,这样会带来一个滞后的问题

本来考虑用mongodb,但是去年由于某个业务应用测试过mongodb的性能,差强人意,想问下你们是如何做到的?


加载中
0
pyruby
pyruby

引用来自“梅开源”的答案

给user_name做索引然后查询很正常,查询速度够快最重要。

如果感觉很慢,注意mysql的版本和配置,选用引擎。

汗,最后测试了下,单独把user_id和user_name这2个字段从用户表里再拎出一张表来,然后从这张表查还是比较块的,而且user_name还没建索引,查寻时间也在1秒之内。原来的用户表里可能是字段太多了,效率很低
0
梅开源
梅开源

给user_name做索引然后查询很正常,查询速度够快最重要。

如果感觉很慢,注意mysql的版本和配置,选用引擎。

0
mark35
mark35
mysql不支持函数索引,不然可以创建一个md5(user_name)的索引。替代办法是新增一个字段保存md5(user_name)值
0
pyruby
pyruby

引用来自“mark35”的答案

mysql不支持函数索引,不然可以创建一个md5(user_name)的索引。替代办法是新增一个字段保存md5(user_name)值

md5的话没多大意义,md5后大小没多大变化,还不如直接给用户名建索引

0
0
pyruby
pyruby

引用来自“幽烛”的答案

sphinx 
让我做实时索引?
0
幽烛
幽烛
这个是有滞后问题,再想想。要么试试memcache,把现有用户名及后新注册的用户名存到内存里,查询应该很快的。当然了,键可以使用md5(用户名),值可去1即可。
0
pyruby
pyruby

引用来自“幽烛”的答案

这个是有滞后问题,再想想。要么试试memcache,把现有用户名及后新注册的用户名存到内存里,查询应该很快的。当然了,键可以使用md5(用户名),值可去1即可。
嗯,这种方法其实是最简单大家都能够想到的方法,但是我们从资源利用角度,暂时还是决定放在mysql,就想我说的那种方法去实施的
返回顶部
顶部