字符串加索引

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

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

前缀索引

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

取字符串中间部分作为子串来建索引—fulltext索引。like ‘%name%’模糊查询使用全文检索索引。

前缀索引占用的空间会更小，但是会增加额外的扫描次数。使用前缀索引，定义好长度，就可以做到既节省空间，又不用额外增加太多的查询成本。

确定前缀长度

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

首先，统计出改列上有多少个不同的值：
1
select count(distinct email) as L from suser;

依次选取不同长度的前缀再来统计该值：

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%的值。

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

char（N）表示“最长存N，但是如果字符串小于N，用空格补到N”。
varchar（N）表示“最长存N，如果字符串小于N，按照实际长度来存”。

影响覆盖索引

使用前缀索引用不上覆盖索引对查询性能的优化。

1 2	select id,email from suser where email = 'abcdefg@xyz.com'; select id,name,email from suser where email = 'abcdefg@xyz.com';

如果使用index1(email整个字符串的索引结构)，可以利用覆盖索引，从index1查到结果后直接就返回了，不需要回到主键ID索引再去查一次；
如果使用index2(email(n)前缀索引结构)，不得不回到主键ID索引再去判断email字段的值。

即使将index2的定义修改为email(11)的前缀索引，这时虽然index2已经包含了所有的信息，但是InnoDB还是要回到id索引再查一下，拿到该主键值对应的行，再判断email是否正确。因为系统并不确定前缀索引的定义是否截断了完整信息，以防email字段返回的值不对。

倒序存储

身份证号，一共18位，其中前6位是地址码，同一个县的人的身份证号前6位一般是相同的。
对身份证号做长度为6的前缀索引的话，区分度非常低；创建长度为12以上的前缀索引能满足区分度要求，但是占用的磁盘空间过大。

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

存储身份证号的时候把它倒过来存，每次查询的时候将输入的字符串反转后再查。
身份证的最后6位没有地址码这样的重复逻辑，做前缀索引提供了足够的区分度。

使用hash字段

1 2	alter table t add id_card_crc int unsigned, add index(id_card_crc); select field_list from t where id_card_crc=crc32('input_id_crad_string') and id_card='input_id_card_string';

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

每次插入新纪录的时候，都同时用crc32()这个函数得到检验码填到这个新字段。校验码可能存在冲突，查询语句where部分要判断id_card的值是否精确相同。

索引长度比原来小，只需要四个字节。

倒序存储和使用hash字段对比

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

不同点：

从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而hash字段方法需要增加一个字段。倒序存储方式使用4个字节的前缀长度应该是不够的，如果再长一点，这个消耗跟额外这个hash字段差不多抵消。
在CPU消耗方面，倒序方式每次写和读的时候，都需要额外调用依次reverse函数，而hash字段的方式需要额外调用依次crc32()函数。如果只从这两个函数的计算复杂度来看，reverse函数额外消耗的CPU资源会更小一些。
从查询效率看，使用hash字段方式的查询性能相对稳定。crc32算出来的值虽有冲突的概率，但是比较小，可以认为每次查询的平均扫描函数接近1.而倒序存储方式毕竟还是用的前缀索引的方式，还会增加扫描行数。