文章目录
- 前言
- 一、前缀索引和普通索引
- 二、前缀索引对覆盖索引的影响
- 三、优化前缀索引
前言
学完了MySQL索引部分,我们清楚的认识到给子段添加索引可以快速的进行查询,节约时间。但是索引有很多。那么对于字段怎么加索引,加什么索引。加到索引不同,效率肯定也会有不同的。接下来,我们研究下,怎么给字符串字段加索引
一、前缀索引和普通索引
我们依旧是通过一个例子进行讲解。
我们用邮箱登录这个业务。创建了一个用户表,SQL句如下:
create table SUser(ID bigint unsigned primary key,email varchar(64),...)engine=InnoDB;
要是有邮箱登录,业务代码中一定会出现如下这样的SQL语句:
select f1,f2 from SUser where email='xxx';
对于这查询语句,相比加上索引效率效率更高。
但是加上什么索引呢?
如果只是普通的加上索引,那么相应的索引对应的B+树中存储的就这email索引列的全部内容。想必都知道,一个邮箱账号包含的字符串是很长。如果把这一个很长的字符串充当索引,那是很浪费存储空间的。为此,我们可以使用前面提到过前缀索引,即把email的一部分字符串设置为索引。接下来,我们分析学习下两者的效率。
针对email字段创建如下两个不同的索引,进行分析:
alter table SUser add index index1(email);
或者
alter table SUser add index index2(email(6));
第一个语句创建的index1索引里面,包含了每个记录的整个字符串;而第二个语句创建的index2
索引里面,对于每个记录都是只取前6个字节。
针对这两个的存储,存储结构图,如下所示:
对index1:
对index2:
从图中的存储可以看出,email(6)这个存储占用的空间更小。这是使用前缀索引的优势,但是查询效率上呢,接下来我们分析一下。
执行下面的SQL语句,看看不同的索引执行流程有何不同:
select id,name,email from SUser where email='zhangssa@xxx.com';
如果使用的是index1(即email整个字符串的索引结构),执行顺序是这样的:
- 从index1索引树找到满足索引值的这条记录,取得ID2的值;
- 到主键上查到主键值是ID2的行,判断email的值是正确的,将这行记录加入结果集;
- 取index1索引树上刚刚查到的位置的下一条记录,发现已经不满足条件了,循环结束。
这个过程中,只需要回主键索引取一次数据,所以系统认为只扫描了一行。
如果使用的是index2 (即email(6)索引结构),执行顺序是这样的:
- 从index2索引树找到满足索引值是’zhangs’的记录,找到的第一个是ID1;
- 到主键上查到主键值是ID1的行,判断出email的值不是这行记录丢弃;
- 取index2上刚刚查到的位置的下一条记录,发现仍然是’zhangs’,取出ID2,再到ID索引上取整行然后判断,这次值对了,将这行记录加入结果集;
- 重复上一步,直到在idxe2上取到的值不是’zhangs’时,循环结束。
通过这个对比,你很容易就可以发现,使用前缀索引后,可能会导致查询语句读数据的次数变多。
通过看使用前缀索引结构,进行检索。如果设置的前缀个数较少,那各个字段的区分度不大,就会有很多重合的索引,就需要多次回表进行检查。区分度越高越好。因为区分度越高,意味着重复的键值越少。但是要存储的字符串就会越多,所以要平衡下,找到最好的前缀索引。
二、前缀索引对覆盖索引的影响
我们将上面的SQL查询语句,变成下面的:
select id,email from SUser where email='zhansss%@xxx.com';
如果使用index1(即email整个字符串的索引结构)的话,可以利用覆盖索引,从index1查
到结果后直接就返回了,不需要回到ID索引再去查一次。而如果使用index2(即email(6)索引结
构)的话,就不得不回到ID索引再去判断email字段的值。
将index2的定义修改为email(18)的前缀索引,这时候虽然index2已经包含了所有的信息,但InnoDB还是要回到id索引再查一下,因为系统并不确定前缀索引的定义是否截断了完整信
也就是说,使用前缀索引就用不上覆盖索引对查询性能的优化了,这也是你在选择是否使用前缀
索引时需要考虑的一个因素。
对前缀索引方式的优化
三、优化前缀索引
对于邮箱这样的使用前缀比较合适,但是如果像身份证这样的,因为身份证前很多位都是表示地理信息的,所以每个人的区分度不大。
为了解决这个区分度的问题,设计了如下两种方法:
第一种方式:倒序存储
存储身份证号的时候把它倒过来存,每次查询的时候,可以这么写:
select field_list from t where id_card=reverse('input_id_card_string');
第二种方式:使用hash字段
在表上再创建一个整数字段,来保存身份证的校验码,同时在这个字段上创建索引:
alter table t add id_card_crc int unsigned, add index(id_card_crc);
每次插入新记录的时候,都同时用crc32()这个函数得到校验码填到这个新字段。由于校验码可能存在冲突,也就是说两个不同的身份证号通过crc32()函数得到的结果可能是相同的,所以你的查询语句where部分要判断id_card的值是否精确相同。
它们这两个都不支持范围查询。倒序存储的字段上创建的索引是按照倒序字符串的方式排序的,已经没有办法利用索引方式查出身份证号码在[ID_X, ID_Y]的所有市民了。同样
地,hash字段的方式也只能支持等值查询。
键值越少。