几乎所有的系统都支持邮箱登录，现在维护一个支持邮箱登录的系统，用户表是这么定义的：
create table SUser(
ID bigint unsigned primary key,
email varchar(64),
...
)engine=innodb;由于要使用邮箱登录，所以业务代码中一定会出现类似于这样的语句：
select f1, f2 from SUser where email='xxx';根据索引的知识，如果email这个字段上没有索引，那么这个语句就只能做全表扫描。同时，MySQL是支持前缀索引的，可以定义字符串的一部分作为索引。如果创建索引的语句不指定前缀长度，那么索引就会包含整个字符串。
alter table SUser add index index1(email);或
alter table SUser add index index2(email(6)); 第一个语句创建的index1索引里面，包含了每个记录的整个字符串；而第二个语句创建的index2索引里面，对于每个记录都是只取前6个字节。两个索引的示意图如下： 
select id,name,email from SUser where email='zhangssxyz@xxx.com';如果使用的是index1（即email整个字符串的索引结构），执行顺序如下：
- 从index1索引树找到满足索引值是’zhangssxyz@xxx.com’的这条记录，取得ID2的值；
- 到主键上查到主键值是ID2的行，判断email的值是正确的，将这行记录加入结果集；
- 取index1索引树上刚刚查到的位置的下一条记录，发现已经不满足email='zhangssxyz@xxx.com’的条件了，循环结束。 这个过程中，只需要回主键索引取一次数据，所以系统认为只扫描了一行。
如果使用的是index2（即email(6)索引结构），执行顺序如下：
- 从index2索引树找到满足索引值是’zhangs’的记录，找到的第一个是ID1；
- 到主键上查到主键值是ID1的行，判断出email的值不是’zhangssxyz@xxx.com’，这行记录丢弃；
- 取index2上刚刚查到的位置的下一条记录，发现仍然是’zhangs’，取出ID2，再到ID索引上取整行然后判断，这次值对了，将这行记录加入结果集；
- 重复上一步，直到在index2上取到的值不是’zhangs’时，循环结束。 在这个过程中，要回主键索引取4次数据，也就是扫描了4行。
发现使用前缀索引后，可能会导致查询语句读数据的次数变多。但是，如果定义的index2是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(email,7))as L7,
from SUser;需要预先设定一个可以接受的损失比例，比如5%。然后，在返回的L4~L7中，找出不小于 L * 95%的值，若L6、L7都满足，就可以选择前缀长度为6。
使用前缀索引可能会增加扫描行数，这会影响性能。其实，前缀索引的影响不止如此。
select id,email from SUser where email='zhangssxyz@xxx.com';与前面的sql语句相比，此语句只要求返回id和email
- 如果使用index1（email整个字符串的索引结构），可以利用覆盖索引，从index1查到结果后直接就返回了，不需要回到ID索引再去查一次。
- 如果使用index2（email(6)索引结构），不得不回到ID索引再去判断email字段的值。
所以使用前缀索引就用不上覆盖索引对查询性能的优化了，这也是在选择是否使用前缀索引时需要考虑的一个因素。
对于类似于邮箱这样的字段来说，使用前缀索引的效果可能还不错。但也会遇到前缀的区分度不够好的情况，比如，身份证号。
如果维护的数据库是一个市的公民信息系统，这时候如果对身份证号做长度为6的前缀索引的话，这个索引的区分度就非常低了。
按照前面的方法，可能需要创建长度为12以上的前缀索引，才能够满足区分度要求。但是，索引选取的越长，占用的磁盘空间就越大，相同的数据页能放下的索引值就越少，搜索的效率也就会越低。
3.1 倒序存储
select field_list from t where id_card = reverse('input_id_card_string');由于身份证号的最后6位没有地址码这样的重复逻辑，所以最后这6位很可能就提供了足够的区分度。
3.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('input_id_card_string') and id_card='input_id_card_string';3.3 两种方法的异同点
相同点： 都不支持范围查询。
- 倒序存储的字段上创建的索引是按照倒序字符串的方式排序的，已经没有办法利用索引方式查出身份证号码在[ID_X, ID_Y]的所有市民了。
- hash字段的方式也只能支持等值查询。
区别：
- 从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而hash字段方法需要增加一个字段。
- 在CPU消耗方面，倒序方式每次写和读的时候，都需要额外调用一次reverse函数，hash字段的方式需要额外调用一次crc32()函数。如果只从这两个函数的计算复杂度来看的话，reverse函数额外消耗的CPU资源会更小些。
- 从查询效率上看，使用hash字段方式的查询性能相对更稳定一些。因为crc32算出来的值虽然有冲突的概率，但是概率非常小。而倒序存储方式毕竟还是用的前缀索引的方式，还是会增加扫描行数。
维护一个学校的学生信息数据库，学生登录名的统一格式是”学号@gmail.com", 而学号的规则是：15位的数字，其中前3位是所在城市编号、第4到第6位是学校编号、第7位到第10位是入学年份、最后5位是顺序编号。
系统登录的时候都需要学生输入登录名和密码，验证正确后才能继续使用系统。
解答： 由于这个学号的规则，无论是正向还是反向的前缀索引，重复度都比较高。因为维护的只是一个学校的，因此前面6位是固定的，邮箱后缀都是@gamil.com，因此可以只存入学年份加顺序编号，它们的长度是9位。 而其实在此基础上，可以用数字类型来存这9位数字。比如201100001，这样只需要占4个字节。其实这个就是一种hash，只是它用了最简单的转换规则：字符串转数字的规则。