给字符串加索引：

如果创建的索引不指定长度的话，那么索引会包含整个字符串，如果指定长度，那么就是前缀索引。

• 给整个字段加索引，如果字段占用的内存较大，那么数据页一页所能存储的数据会小很多。InnoDB数据页默认大小是16KB。
• 如果给字段加的是前缀索引，肯定是比这个字段加索引占用空间要小，存储的索引项会更多。这就是前缀索引的优势，但是使用前缀索引会增加扫描的次数。

前缀索引为什么会增加扫描的次数呢？

比如现在有一个email表，其中有email号字段。

比如有zhangsan111@gmail，zhangsan222@gmail，zhangsan333@gmail这三条记录。

如果是email(8)这样建立的前缀索引的话，那么想，在索引树上查找’zhangsan’的索引值，找到了返回id，然后在回表，去主键索引上去查找email的值，判断对不对，对就将这行收入结果集当中。然后在前缀索引的索引树当中接着上条查询的位置接着查’zhangsan’，查到之后在返回主键判断…

在来看，如果不是前缀索引，在索引树中查到email之后回表去主键上判断，是就收入结果集，在去查，发现不对，查询就结束了。

系统中认为查询主键索引的次数为扫描的行数。

所以使用不使用前缀索引只扫描了一行，使用前缀索引扫描了4行。

结论：使用前缀索引可能会导致查询语句读数据的次数变多。但是如果你使用前缀索引，定义好长度，就可以做到既节省空间，又不用额外增加太多的查询成本。

如何确定我应该使用多长的前缀呢？

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

select count(distinct 字段) from table;

可以这样查看有多少不同值。

然后依次选取不同长度的前缀来看这个值

select count(distinct left(字段,4)）as L4, count(distinct left(字段,5)）as L5, count(distinct left(字段,6)）as L6, count(distinct left(字段,7)）as L7,from 表名;

当然，使用前缀索引很可能会损失区分度，所以你需要预先设定一个可以接受的损失比例，比如 5%。然后，在返回的 L4~L7 中，找出不小于 L * 95% 的值，假设这里 L6、L7 都满足，你就可以选择前缀长度为 6。

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

使用前缀索引用不上覆盖索引（点击查看覆盖索引的概念）对查询性能的优化。因为是前缀的，所以需要回表再次判断的，覆盖索引肯定就用不上了。即使用字段的长度作为前缀长度，也不可以利用覆盖索引的概念，因为系统并不确定前缀索引的定义是否截断了完整信息。

还有其他方式能解决吗？

• 倒叙存储

  在存储的时候倒叙来存，查询用到的话利用MySQL的reserve()函数就行。

• Hash字段

  可以在表上再创建一个整数字段，来保存hash码，同时在这个字段上创建索引。

使用倒序存储和使用 hash 字段这两种方法的异同点 。

首先，它们的相同点是，都不支持范围查询。同样地，hash 字段的方式也只能支持等值查询。

它们的区别，主要体现在以下三个方面：

• 从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而 hash 字段方法需要增加一个字段。

• 在 CPU 消耗方面，倒序方式每次写和读的时候，都需要额外调用一次 reverse 函数，而 hash 字段的方式需要额外调用一次函数。如果只从这两个函数的计算复杂度来看的话，reverse 函数额外消耗的 CPU 资源会更小些。

• 从查询效率上看，使用 hash 字段方式的查询性能相对更稳定一些。因为hash函数算出来的值虽然有冲突的概率，但是概率非常小，可以认为每次查询的平均扫描行数接近 1。而倒序存储方式毕竟还是用的前缀索引的方式，也就是说还是可能会增加扫描行数。

总结：

• 直接创建完整索引，这样可能比较占用空间；
• 创建前缀索引，节省空间，但会增加查询扫描次数，并且不能使用覆盖索引；
• 倒序存储，再创建前缀索引，用于绕过字符串本身前缀的区分度不够的问题；
• 创建 hash 字段索引，查询性能稳定，有额外的存储和计算消耗，和倒叙存储一样，都不支持范围扫描。