Mysql性能优化:如何给字符串加索引?
爱撒谎的男孩 人气:0导读
-
现代大部分的登录系统都支持邮箱、手机号码登录两种方式,那么如何在邮箱或者手机号码这个字符串上建立索引才能保证性能最佳呢?
-
今天这篇文章就来探讨一下在Mysql中如何给一个字符串加索引才能达到性能最佳。
- 本文首发于作者的微信公众号【码猿技术专栏】,原创不易,喜欢的朋友支持一下,谢谢!!!
-
陈某将会从什么是前缀索引、前缀索引和普通索引的比较、如何建丽最佳性能的前缀索引、前缀索引对覆盖索引的影响这几段来讲。
前缀索引
-
顾名思义,对于列值较长,比如
BLOB
、TEXT
、VARCHAR
,就 "必须" 使用前缀索引,即将值的前一部分作为索引。因为索引的存储也是需要空间的,同样索引太长维护起来也比较困难。 -
比如我们给
User
表中的邮箱添加前缀索引,如下:
alter table user add index index1(email(7));
-
上述语句将email的前7个字符作为索引。
前缀索引和普通索引比较
-
我们分别将
email
的全部作为索引和前7个字符作为索引来看看在性能上有什么差异。建立索引的语句如下:
alter table user add index index1(email);
alter table user add index index2(email(7));
-
假设有
user
表中有这样几条数据(id,name,email):(1,"陈某","chenmou1993@xxx")
、(2,"张某","chenmou1994@xxx")
、(3,"李某","chenmou1995@xxx")
、(4,"王某","chenmou1996@xxx")
。 -
对应于index1和index2的索引树如下两张图:
-
如果执行下面的查询语句,Mysql如何利用索引来查询呢?
select * from user where email="chenmou1995@xxx";
【1】普通索引的执行过程
-
从index1索引树找到满足索引值是
chenmou1995@xxx
的这条记录,取得id=2
的值; -
到主键上查到主键值是
id=2
的行,判断email的值是正确的,将这行记录加入结果集; -
取
index1
索引树上刚刚查到的位置的下一条记录,发现已经不满足email=chenmou1995@xxx
的条件了,循环结束。
这个过程中,只需要回主键索引取一次数据,所以系统认为只扫描了一行。
【2】前缀索引的执行过程
-
从index2索引树找到满足索引值是
chenmou
的记录,找到的第一个是id=1; -
到主键上查到主键值是id=1的行,判断出email的值不是
chenmou1995@xxx
,这行记录丢弃; -
取index2上刚刚查到的位置的下一条记录,发现仍然是
chenmou
,取出id=2,再到ID索引上取整行然后判断,这次值对了,将这行记录加入结果集; -
重复上一步,直到在idxe2上取到的值不是
chenmou
时,循环结束。
在这个过程中,要回主键索引取4次数据,也就是扫描了4行。
-
通过以上查询的对比,很容易就可以发现,使用前缀索引后,可能会导致查询语句读数据的次数变多。
-
但是对于这个查询语句来说,如果建立的前缀索引的长度为13呢?那么满足
chenmou1995
的记录只有一个,这样就可以直接定位到id=2
,此时不但空间缩小了,扫描的行数也减少了。 -
于是结论就来了:使用前缀索引,只要定义好长度,就可以做到既节省空间,又不用额外增加太多的查询成本。
-
那么如何建立正确的前缀索引才能达到最佳的性能呢?接着往下看................
如何建立最佳性能的前缀索引
-
通过上述的比较,可以得出一个结论,建立前缀索引的区分度越高越好,意味着重复的键值越少。
-
那么如何统计区分度,其实很简单,只需要判断数据库中重复的次数即可。sql如下:
select
count(distinct left(email,4))as L4,
count(distinct left(email,5))as L5,
count(distinct left(email,6))as L6,
count(distinct left(email,7))as L7,
from user;
-
但是如果对于使用前缀区分度不太好的情况,比如,我们国家的SFZ号,一共18位,其中前6位是地址码,所以同一个县的人的SFZ号前6位一般会是相同的。 这时候如果对SFZ号做长度为6的前缀索引的话,这个索引的区分度就非常低了。
-
按照我们前面说的方法,可能你需要创建长度为12以上的前缀索引,才能够满足区分度要求。
-
但是,索引选取的越长,占用的磁盘空间就越大,相同的数据页能放下的索引值就越少,搜索的效率也就会越低。
-
那么,如果我们能够确定业务需求里面只有按照SFZ进行等值查询的需求,还有没有别的处理方法呢?这种方法,既可以占用更小的空间,也能达到相同的查询效率。现在简单的介绍一种解决此种问题的方式,当然方法肯定不止一种,如下:
倒序存储
如果你存储SFZ号的时候把它倒过来存,每次查询的时候,你可以这么写:
select field_list from t where id_card = reverse('输入的SFZ号');
由于SFZ号的最后6位没有地址码这样的重复逻辑,所以最后这6位很可能就提供了足够的区分度。当然了,实践中你不要忘记使用count(distinct)
方法去做个验证。
前缀索引对覆盖索引的影响
-
前缀索引会导致覆盖索引失效,查询语句如下:
select id,name from user where email="chenmou1995@xxx";
-
由于使用了前缀索引,因此必须会回表验证查询到的时候正确,此处使用了覆盖索引也是无效的。
-
也就是说,使用前缀索引就用不上覆盖索引对查询性能的优化了,这也是你在选择是否使用前缀索引时需要考虑的一个因素。
总结
-
如何给字符串加索引是一个需要考量的问题,陈某在这里给出如下的建议:
-
如果字符串长度很短,建议直接用全部作为索引。
-
使用前缀索引注意分析区分度,区分度越高越好。
-
使用前缀索引需要考虑覆盖索引失效的问题。
加载全部内容