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

如今，几乎全部的系统都支持邮箱登陆，如何在邮箱这样的字段上创建合理的索引，是咱们今天要讨论的问题。

假设，你如今维护一个支持邮箱登陆的系统，用户表是这么定义的：

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

因为要使用邮箱登陆，因此业务代码中必定会出现相似于这样的语句：

mysql> select f1, f2 from SUser where email='xxx';

从第4和第5篇讲解索引的文章中，咱们能够知道，若是email这个字段上没有索引，那么这个语句就只能作全表扫描。

同时，MySQL是支持前缀索引的，也就是说，你能够定义字符串的一部分做为索引。默认地，若是你建立索引的语句不指定前缀长度，那么索引就会包含整个字符串。

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

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

第一个语句建立的index1索引里面，包含了每一个记录的整个字符串；而第二个语句建立的index2索引里面，对于每一个记录都是只取前6个字节。

那么，这两种不一样的定义在数据结构和存储上有什么区别呢？如图2和3所示，就是这两个索引的示意图。

图1 email 索引结构

图2 email(6) 索引结构

从图中你能够看到，因为email(6)这个索引结构中每一个邮箱字段都只取前6个字节（即：zhangs），因此占用的空间会更小，这就是使用前缀索引的优点。

但，这同时带来的损失是，可能会增长额外的记录扫描次数。

接下来，咱们再看看下面这个语句，在这两个索引定义下分别是怎么执行的。

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

若是使用的是index1（即email整个字符串的索引结构），执行顺序是这样的：

1. 从index1索引树找到知足索引值是’zhangssxyz@xxx.com’的这条记录，取得ID2的值；

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

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

这个过程当中，只须要回主键索引取一次数据，因此系统认为只扫描了一行。

若是使用的是index2（即email(6)索引结构），执行顺序是这样的：

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

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

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

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

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

经过这个对比，你很容易就能够发现，使用前缀索引后，可能会致使查询语句读数据的次数变多。

可是，对于这个查询语句来讲，若是你定义的index2不是email(6)而是email(7），也就是说取email字段的前7个字节来构建索引的话，即知足前缀’zhangss’的记录只有一个，也可以直接查到ID2，只扫描一行就结束了。

也就是说使用前缀索引，定义好长度，就能够作到既节省空间，又不用额外增长太多的查询成本。

因而，你就有个问题：当要给字符串建立前缀索引时，有什么方法可以肯定我应该使用多长的前缀呢？

实际上，咱们在创建索引时关注的是区分度，区分度越高越好。由于区分度越高，意味着重复的键值越少。所以，咱们能够经过统计索引上有多少个不一样的值来判断要使用多长的前缀。

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

mysql> select count(distinct email) as L from SUser;

而后，依次选取不一样长度的前缀来看这个值，好比咱们要看一下4~7个字节的前缀索引，能够用这个语句：

mysql> 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 SUser;

固然，使用前缀索引极可能会损失区分度，因此你须要预先设定一个能够接受的损失比例，好比5%。而后，在返回的L4~L7中，找出不小于 L * 95%的值，假设这里L六、L7都知足，你就能够选择前缀长度为6。

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

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

你先来看看这个SQL语句：

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

与前面例子中的SQL语句

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

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

因此，若是使用index1（即email整个字符串的索引结构）的话，能够利用覆盖索引，从index1查到结果后直接就返回了，不须要回到ID索引再去查一次。而若是使用index2（即email(6)索引结构）的话，就不得不回到ID索引再去判断email字段的值。

即便你将index2的定义修改成email(18)的前缀索引，这时候虽然index2已经包含了全部的信息，但InnoDB仍是要回到id索引再查一下，由于系统并不肯定前缀索引的定义是否截断了完整信息。

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

其余方式

对于相似于邮箱这样的字段来讲，使用前缀索引的效果可能还不错。可是，遇到前缀的区分度不够好的状况时，咱们要怎么办呢？

好比，咱们国家的身份证号，一共18位，其中前6位是地址码，因此同一个县的人的身份证号前6位通常会是相同的。

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

按照咱们前面说的方法，可能你须要建立长度为12以上的前缀索引，才可以知足区分度要求。

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

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

答案是，有的。

第一种方式是使用倒序存储。若是你存储身份证号的时候把它倒过来存，每次查询的时候，你能够这么写：

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

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

第二种方式是使用hash字段。你能够在表上再建立一个整数字段，来保存身份证的校验码，同时在这个字段上建立索引。

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

而后每次插入新记录的时候，都同时用crc32()这个函数获得校验码填到这个新字段。因为校验码可能存在冲突，也就是说两个不一样的身份证号经过crc32()函数获得的结果多是相同的，因此你的查询语句where部分要判断id_card的值是否精确相同。

mysql> 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。而倒序存储方式毕竟仍是用的前缀索引的方式，也就是说仍是会增长扫描行数。

小结

在今天这篇文章中，我跟你聊了聊字符串字段建立索引的场景。咱们来回顾一下，你可使用的方式有：

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

2. 建立前缀索引，节省空间，但会增长查询扫描次数，而且不能使用覆盖索引；

3. 倒序存储，再建立前缀索引，用于绕过字符串自己前缀的区分度不够的问题；

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

在实际应用中，你要根据业务字段的特色选择使用哪一种方式。

好了，又到了最后的问题时间。

若是你在维护一个学校的学生信息数据库，学生登陆名的统一格式是”学号@gmail.com", 而学号的规则是：十五位的数字，其中前三位是所在城市编号、第四到第六位是学校编号、第七位到第十位是入学年份、最后五位是顺序编号。

系统登陆的时候都须要学生输入登陆名和密码，验证正确后才能继续使用系统。就只考虑登陆验证这个行为的话，你会怎么设计这个登陆名的索引呢？

你能够把你的分析思路和设计结果写在留言区里，我会在下一篇文章的末尾和你讨论这个问题。感谢你的收听，也欢迎你把这篇文章分享给更多的朋友一块儿阅读。

上期问题时间

上篇文章中的第一个例子，评论区有几位同窗说没有复现，你们要检查一下隔离级别是否是RR（Repeatable Read，可重复读），建立的表t是否是InnoDB引擎。我把复现过程作成了一个视频，供你参考。

在上一篇文章最后，我给你留的问题是，为何通过这个操做序列，explain的结果就不对了？这里，我来为你分析一下缘由。

delete 语句删掉了全部的数据，而后再经过call idata()插入了10万行数据，看上去是覆盖了原来的10万行。

可是，session A开启了事务并无提交，因此以前插入的10万行数据是不能删除的。这样，以前的数据每一行数据都有两个版本，旧版本是delete以前的数据，新版本是标记为deleted的数据。

这样，索引a上的数据其实就有两份。

而后你会说，不对啊，主键上的数据也不能删，那没有使用force index的语句，使用explain命令看到的扫描行数为何仍是100000左右？（潜台词，若是这个也翻倍，也许优化器还会认为选字段a做为索引更合适）

是的，不过这个是主键，主键是直接按照表的行数来估计的。而表的行数，优化器直接用的是show table status的值。

这个值的计算方法，我会在后面有文章为你详细讲解。