7.前缀索引
使用前缀索引，定义好长度，就可以做到既节省空间（定义索引的字段越短，约减少索引树中页里面的空间。可以联想主键不宜定义过长的字段，因为所有二级索引都需要关联主键的字段值！！），又不用额外增加太多的查询成本（减少回表的次数就是减少IO！！！）。
mysql> select count(distinct email) as L from SUser;
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;
这个语句可以算出每一列前L个字节的不同的数量，来比较区分度，区分度越高，就越能减少回表的次数。
前缀索引对覆盖索引的影响
完全影响了覆盖所有，不论前缀索引在定义的时候截取了多长的字节。在查询中如果只包含主键及前缀索引的字段，都会回表到主键索引！！！！
因为系统并不确定前缀索引的定义是否截断了完整信息。也就是说，使用前缀索引就用不上覆盖索引对查询性能的优化了，这也是你在选择是否使用前缀索引时需要考虑的一个因素。
其他方式
像长的字段并且前面部分的区分度较高的话推荐使用前缀索引，但是像身份证这种又长，而且前面区分度低的，用前缀索引就没效果了。因为索引选取的越长，占用的磁盘空间就越大，相同的数据页能放下的索引值就越少，搜索的效率也就会越低
，所以推荐使用：
第一种方式是使用倒序存储。如果你存储身份证号的时候把它倒过来存，每次查询的时候，你可以这么写：
mysql> select field_list from t where id_card = reverse('input_id_card_string');
当然了，实践中你不要忘记使用 count(distinct) 方法去做个验证。判断某一列的区分度
第二种方式是使用 hash 字段。你可以在表上再创建一个整数字段，来保存身份证的校验码(hash身份证后得到的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'
接下来，我们再一起看看使用倒序存储和使用 hash 字段这两种方法的异同点。首先，
它们的相同点是，都不支持范围查询。倒序存储的字段上创建的索引是按照倒序字符串的方式排序的，已经没有办法利用索引方式查出身份证号码在[ID_X, ID_Y]的所有市民了。同样地，hash 字段的方式也只能支持等值查询
它们的区别，主要体现在以下三个方面：
1.从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而 hash 字段方法需要增加一个字段。当然，倒序存储方式使用 4 个字节的前缀长度应该是不够的，如果再长一点，这个消耗跟额外这个 hash 字段也差不多抵消了。
2.在 CPU 消耗方面，倒序方式每次写和读的时候，都需要额外调用一次 reverse 函数，而 hash 字段的方式需要额外调用一次 crc32() 函数。如果只从这两个函数的计算复杂度来看的话，reverse 函数额外消耗的 CPU 资源会更小些。
3.从查询效率上看，使用 hash 字段方式的查询性能相对更稳定一些。因为 crc32 算出来的值虽然有冲突的概率，但是概率非常小，可以认为每次查询的平均扫描行数接近 1。而倒序存储方式毕竟还是用的前缀索引的方式，也就是说还是会增加扫描行数