怎么给字符串字段加索引？

在使用邮箱登录的时候，怎么在邮箱这样的字段上建立合理的索引？

假如，现在维护一个支持邮箱登录的系统，用户表是这么定义的：

mysql> create table SUser(
ID bigint unsigned primary key,
email varchar(64),
...
)engine=innodb; 

在使用邮箱登录的时候，在业务代码中一定会出现类似于这样的语句：

select f1,f2 from SUser where email = 'xxx'；

如果email这个字段上没有索引，那么这个语句就只能做全表扫描。

同时，Mysql是支持前缀索引的，也就是说，可以定义字符串的一部分作为索引。默认的，如果在创建索引的语句不指定前缀长度，那么索引就会包含整个字符串。

比如，这两个在email字段上创建索引的语句：

mysql> alter table SUser add index index1(email);
或
mysql> alter table Suser add index index1(email(6));

第一个语句创建的index1索引里面，包含了每个记录的整个字符串，第二个语句创建的index1索引里面，只取前6个字节。

这两种不同的定义在数据结构和存储上有什么区别呢？索引示意图如下所示：

第一个index1索引示意图

第二个index1索引示意图

如图所示，第二个index1使用的email(6)索引结构中每个邮箱字段都只取6个字节，所以占用的空间会更小，这就是前缀索引的优势。

这样虽然占用的空间小了，但是同时会带来损失，会增加额外的记录扫描次数。

通过如下语句，看下这两个索引分别是如何执行的：

select id,name,email from SUser where email = 'zhangssxyz@xx.com';

如果是使用的第一个index1索引，执行顺序如下：

1、从index1索引树找到满足索引值是’zhangssxya@xx.com’的这条记录，取得ID2的值；

2、到主键上查到主键值是ID2的行，判断email的值是正确的，将这行记录加入到结果集；

3、取index1索引树上刚刚查到的位置的下一条记录，发现已经不满足email = 'zhangssxya@xx.com’的条件了，循环结束。

这个过程中，只需要回主键索引取一次数据，所以系统认为只扫描了一行。

如果是使用的第二个index1索引，执行顺序如下：

1、从index2索引树找到满足索引值是’zhangs’的记录，找到的第一个是ID1；

2、到主键上查到主键值是ID1的行，判断出email的值不是’zhangssxya@xx.com’,这行记录丢弃；

3、取index2上刚刚查到的位置的下一条记录，发现仍然是’zhangs’，去除ID2，再到ID索引上取整行然后判断，这次值对了，将这行记录加入结果集；

4、重复上一步，直到在index2上取到的值不是’zhangs’时，循环结束。

这个过程中，要回主键索引取4次数据，也就是扫描了4行。

通过对比发现，使用前缀索引后，可能会导致查询语句读数据的次数变多。

但是，对于这个查询sql来说，如果你定义的index2不是email(6)，而是email(7)，也就是说通过取email字段的前7个字节来构建索引的话，即满足前缀’zhangss’的记录只有一个，也能够直接查到ID2，只扫描一行就结束了。

使用前缀索引，定义好长度，就可以做到既节省空间，又不用额外增加太多的查询成本。

那么当要给字符串创建前缀索引时，有什么方法能够确定我应该使用多长的前缀呢？

实际上，我们在建立索引时关注的是区分度，区分度越高越好。因为区分度越高，意味着重复的键值减少。因此，我们可以通过统计索引上有多少个不同的值来判断要使用多长的前缀。

首先，可以使用下面这个语句，算出这个列上有多少个不同的值：

select count(distinct email) as L from SUser;

然后，依次选取不同的长度的前缀来看这个值，比如我们要看一下4~7个字节的前缀索引，可以用这个语句：

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(emial,7)) as L7
from Suser

使用前缀索引很可能会损失区分度，所以需要预先设定一个可以接收的损失比例，比如5%。然后，在返回的L4~L7中，找出不小于L*95%的值，假设这里L6，L7都满足，就可以选择前缀长度为6。

前缀索引对覆盖索引的影响

前面我们说了使用前缀索引可能会增加扫描行数，这会影响到性能。其实，前缀索引的影响不止于此，我们在看一下另外一个场景。

先看如下sql:

select id,email from SUser where email = 'zhangssxyz@xx.com';

前面例子中的sql语句是：

select id,name,email from SUser where email = 'zhangssxyz@xx.com';

相比，这个语句只需要返回id，email两个字段。

所以，如果使用第一个index1的索引的话，可以使用覆盖索引，从index1查到结果后直接就返回了，不需要回到ID索引再去查一次。而如果使用了第二个index1索引的话，就不得不回到ID索引再去判断email字段的值。

即使将第二个index1的索引修改为email(17)的前缀索引，这时候虽然index1包含了所有的信息，但是InnoDB还是要回到id索引在查一下，因为系统并不确定前缀索引的定义是否截断了完整信息。

也就是说，使用了前缀索引就用不上覆盖索引对查询性能的优化了，这也是在选择是否使用前缀索引时需要考虑的一个因素。

其他方式

对于邮箱这种前缀区分度较高的字段，使用前缀索引的效果可能还不错，如果遇到前缀区分度不够好的情况时，我们要怎么办呢？

比如，身份证号一共18位，前6位是地址码，所以同一个县的人的身份证号前6位一般会是相同的。

假设维护的数据库是一个市的公民信息系统，这时候如果对身份证号做长度为6的前缀索引，这个索引的区分度就非常低了。

按照前面的说法，可能需要创建长度为12以上的前缀索引，才能够满足区分度要求。

但是，索引选取的越长，占用的磁盘空间就越大，相同的数据页能放下的索引值就越少，搜索的效率也就会越低，

如果我们能够确定业务需求里面只有按照身份证进行等值查询的需求，还有没有别的处理方法呢？这种方法，既可以占用更小的空间，也能达到相同的查询效率。

肯定是有的。

第一种方式是使用倒叙存储

如果你存储身份证号的时候把它倒过来存，每次查询的时候，你可以这么写：

select field_list from t where id_card = reverse('input_id_card_string');

由于身份证号的最后6位没有地址码这样的重复逻辑，所以最后这6位很可能就提供了足够的区分度。当然了，实践中你不要忘记使用count(distinct)方法去做个验证。

第二种方式是使用hash字段

在表上再创建一个整数字段，来保存身份证的校验码，同时在这个字段上创建索引。

alter table t add id_card_crc int unsigned,add index(id_card_crc);

然后每次插入新纪录的时候，都同时用crc32()这个函数得到校验码填到这个新字段，由于验证码可能存在冲突，也就是说两个不同的身份证号通过crc32()函数得到的结果可能是相同的，所以你得查询语句where 部分要判断id_card的值是否精确相同。

select field_list from t where id_card_crc = crc32('input_id_card_string') and id_card = 'input_id_card_string';

这样，索引的长度变成了4个字节，比原来小很多。

使用倒序存储和使用hash字段这两种方法的异同点

相同点

都不支持范围查询。倒序存储的字段上创建的索引是按照倒序字符串的方式排序的，已经没有办法利用索引方式查出身份证号码在[ID_X,ID_Y]的所有市民了。同样地，hash字段的方式也只能支持等值查询。

不同点

1、从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而hash字段方法需要增加一个字段，当然，倒序存储方式使用4个字节的前缀长度应该是不够的，如果再长一点，这个消耗跟额外这个hash字段也差不多抵消了。

2、在CPU消耗方面，倒序方式每次写和读的时候，都需要额外调用一次reverse函数，而hash字段的方式需要额外调用一次crc32()函数。如果只从这两个函数的计算复杂度来看的话，reverse函数额外消耗的CPU资源会更小些

3、从查询效率上看，使用hash字段方式的查询性能相对更稳定一些。因为crc32算出来的值虽然有冲突的概率，但是概率非常小，可以认为每次查询的平均扫描行数接近1。而倒序存储方式毕竟还是用的前缀索引的方式，也就是说还是会增加扫描行数。

总结

直接创建完整索引，这样可能比较占用空间；

创建前缀索引，节省空间，但会增加查询扫描次数，并且不能使用覆盖索引；

倒序存储，再创建前缀索引，用于绕过字符串本身前缀的区分度不够的问题；

创建 hash 字段索引，查询性能稳定，有额外的存储和计算消耗，跟第三种方式一样，都不支持范围扫描。