现在，几乎所有的系统都支持使用邮箱登陆，那么怎样在邮箱这样的字段上创建合理的索引。
假设用户表是这么定义的：
mysql> create table SUser(
ID bigint unsigned primary key,
email varchar(64),
...
)engine=innodb;
由于要使用邮箱登陆，所以业务代码中一定会出现类似于这样的语句：
mysql> select f1,f2 from SUser where email='xxx';
1、前缀索引
我们知道，如果email字段没有索引，那么这个语句会做全表扫描。
对于email字段有两种创建索引的方式：
- 不指定长度，那么索引就会包含整个字符串
mysql> alter table SUser add index index1(email);
- 定义字符串的一部分作为索引
mysql> alter table SUser add index index2(email(6));
那么，这两种索引在数据结构和存储上有什么区别呢？如下图所示
两种建索引的数据结构和存储示例
从图中可以看到，由于email(6)这个索引结构中每个邮箱字段只取前6个字节，所以占用空间会更小，这是使用前缀索引的优势。
但，缺点是会增加而外的记录扫描次数。
接下来，我们再看看下面这个语句，在这两个索引定义下分别是怎么执行的。
select id,name,email from SUser where email='zhangsun@qq.com';
- 使用index1，执行顺序如下
- 从index1索引树找到满足索引值是
zhangsun@qq.com的这条记录，取得R2的值 - 到主键上查找主键值是R2的行，将这行记录加入结果集
- 取index1 索引树上刚刚查到的位置的下一条记录，发现已经不满足where 中的条件，循环结束
整个过程中，只需要回主键索引取一次数据，所以系统认为只扫描了一行。
- 使用index2，执行顺序如下：
- 从index2 索引树找到满足索引值是‘zhangs’的记录，找到第一个是R1
- 回表查询主键值是R1的行，判断出email的值不是
zhangsun@qq.com，丢弃这行记录 - 到index2索引树上取下一条记录，发现仍然是‘zhangs’，再回表查询出R2的行，判断出满足条件，将这行记录加入结果集
- 重复上一步，直到在 index2 上取到的值不是‘zhangs’，循环结束
在这个过程中，要回表查4次数据，也就是扫描了4行。
通过对比可以发现，使用前缀索引后，可能会导致查询语句读取数据的次数变多。
但是，对于这个查询语句来说，如果定义的index2不是6位，而是7位，可以做到只查询一次就获得结果。
也就是说使用前缀索引，定义好长度，就可以做到既节省空间，又不用而外增加太多的查询成本。
那么有什么办法能够确定应该使用多长的前缀呢？
实际上，我们建立索引的时关注的是区分度，区分度越高越好。因为区分度越高，意味着重复的键值越少。因此我们可以通过统计索引上又多少个不同的值来判断要使用多长的前缀。
先统计出这个列上有多少个不同的值
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(email,7)) as L7
from SUser;
当然，使用前缀索引很可能会损失区分度，所以需要预先设定一个可以接受的损失比例，比如5%。然后，在返回的 L4～L7中，找出不小于 L*95%的值，选取满足条件的最小长度即可。
前缀索引对覆盖索引的影响
使用前缀索引可能会增加扫描行数，这会影响到性能。其实，前缀索引的影响不止如此，例如如下场景：
select id,email from SUser where email='zhangsun@qq.com';
这个语句只要求返回id和email字段。
如果使用index1的话，可以利用覆盖索引，从index1查到结果后就直接返回了，不需要回表查询。
如果使用index2的话，需要回表查询，不能利用覆盖索引。
也就是说，使用了前缀索引就用不上覆盖索引多查询性能的优化了，在选择是否使用前缀索引时需要考虑。
2、其他方式
对于类似邮箱这样的字段来说，使用前缀索引的效果可能还不错。但是，遇到前缀的区分度不够好的情况时，我们要怎么办呢？
比如，我们的身份证，一共18位，其中前6位是地址码，所以同一个县的人的身份证号前6位一般是相同的。
如果现在正在做的系统是某个市的公民信息系统，这时候使用前缀索引，前6位的区分度就比较低了。
按照我们前面的方法，可能需要创建长度为12位以上的前缀索引，才能够满足区分度要求。
但是，索引选取的越长，占用的磁盘空间就越大，相同的数据页能放下的索引值就越少，搜索的效率也就会越低。
那么对于这种情况，有没有既可以占用更小的空间，也能达到很高的查询效率？
- 方式1：使用倒序存储
由于身份证号的最后6位没有地址码这样的重复逻辑，所以最后这6位很可能就提供了足够的区分度。
select field_list from t where id_card=reverse('in_id_card')
- 方式2：使用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('in_id_card') and id_card='in_id_card';
这样，索引的长度就变成了4个字节，比原来小很多。当然hash索引的长度越大，产生的hash碰撞概率就越小。
倒序和hash的异同点
相同点：
- 都不支持范围查询，只能等值查询
不同点：
- 占用额外空间，倒序存储方式在主键索引上，不会消耗额外的存储空间，而hash索引需要增加一个字段。当然倒序排序建立索引的长度可能要更长。
- cpu消耗方面，倒序索引的reverse比hash索引crc32的CPU资源消耗要小点
- 查询效率，使用hash索引相对性能更稳定一些。倒序索引的冲突概率要高一些
在实际应用中，需要根据业务字段的特点选择使用哪种方式。
网友评论