MySQL 前缀索引——让索引减负狂奔

什么是前缀索引

　　咱们吃甘蔗的时候，若出现虫蛀状况，咱们不能判断虫蛀的范围有大，若是为了省事，直接砍去若干节，虫蛀残留的几率就会小不少，可是极可能损失更多的可食用甘蔗。若是一点点地削，直至虫蛀再也不出现为止，看起来多花了点功夫，可是浪费的少，也只值得。

　　相比于砍甘蔗，MySQL 的全文索引相似于第一种方法，前缀索引则像是第二种方法。

　　当须要以某个数据类型是字符串的列为索引时，一般都是建立全文索引，经过全文匹配条件来筛选记录。其实没有必要，一种更好的办法是：

能够索引开始的部分字符，这样能够大大节约索引空间，从而提升索引效率

为何要使用前缀索引

• 大大节约索引空间，从而提升索引效率
• 对于 BOLB、TEXT 或者很长的 VARCHAR 类型的列，必须使用前缀索引。由于 MySQL 不容许索引这些列的完整长度

索引的选择性

　　也许咱们心中已经留下了前缀索引效率高于全文索引的印象，可是前缀的长度该保留多少呢？有没有一个标准的值呢？换句话说，索引的长度与查询效率之间呈现怎样的关系？

　　首先，引入一个概念——索引的选择性：

不重复的索引值（也称基数）和数据表记录总数（#T）的值，范围从 1 / #T 到 1 之间。

　　索引的选择性越高则查询效率越高，由于选择性高的索引可让 MySQL 在查找时过滤掉更多的行。对比之下，惟一索引（值惟一，好比主键）的选择性是 1，这是最好的索引选择性，性能也是最好的。

　　前缀索引会下降索引的选择性，由于使用前缀索引查询出的基数很难完美匹配 #T，可是比起这些缺点，前缀索引的好处简直是大过天。

　　真正的难点在于：要选择足够长的前缀以保证较高的选择性，同时又不能太长。前缀的长度应该使前缀索引的选择性接近索引整个列，即前缀的“基数”应该接近于完整列的“基数”。

举例说明

　　下面的例子，查询软件名称，并统计其数量

统计 #T

　　第一列的统计数量则可认为是 #T，如今要查找到最频繁出现（基数接近 #T ）的软件名称前缀，直接从 7 个前缀字母开始：

前缀长度为 7 索引

　　每一个前缀都比原来的软件名称出现的次更多，所以惟一前缀比惟一软件名称要少得多。而后咱们增长前缀长度，直到这个前缀的选择性接近完整列的选择性，此时的前缀长度为 9：

前缀长度为 9 索引

　　试过 10，和 9 差很少，最后，选择了前缀长度为 9 的索引。 　　

　　个人博客地址：MySQL 高性能索引以前缀索引