MySQL 前綴索引——讓索引減負狂奔

什麼是前綴索引

　　咱們吃甘蔗的時候，若出現蟲蛀狀況，咱們不能判斷蟲蛀的範圍有大，若是爲了省事，直接砍去若干節，蟲蛀殘留的機率就會小不少，可是極可能損失更多的可食用甘蔗。若是一點點地削，直至蟲蛀再也不出現爲止，看起來多花了點功夫，可是浪費的少，也只值得。

　　相比於砍甘蔗，MySQL 的全文索引相似於第一種方法，前綴索引則像是第二種方法。

　　當須要以某個數據類型是字符串的列爲索引時，一般都是建立全文索引，經過全文匹配條件來篩選記錄。其實沒有必要，一種更好的辦法是：

能夠索引開始的部分字符，這樣能夠大大節約索引空間，從而提升索引效率

爲何要使用前綴索引

• 大大節約索引空間，從而提升索引效率
• 對於 BOLB、TEXT 或者很長的 VARCHAR 類型的列，必須使用前綴索引。由於 MySQL 不容許索引這些列的完整長度

索引的選擇性

　　也許咱們心中已經留下了前綴索引效率高於全文索引的印象，可是前綴的長度該保留多少呢？有沒有一個標準的值呢？換句話說，索引的長度與查詢效率之間呈現怎樣的關係？

　　首先，引入一個概念——索引的選擇性：

不重複的索引值（也稱基數）和數據表記錄總數（#T）的值，範圍從 1 / #T 到 1 之間。

　　索引的選擇性越高則查詢效率越高，由於選擇性高的索引可讓 MySQL 在查找時過濾掉更多的行。對比之下，惟一索引（值惟一，好比主鍵）的選擇性是 1，這是最好的索引選擇性，性能也是最好的。

　　前綴索引會下降索引的選擇性，由於使用前綴索引查詢出的基數很難完美匹配 #T，可是比起這些缺點，前綴索引的好處簡直是大過天。

　　真正的難點在於：要選擇足夠長的前綴以保證較高的選擇性，同時又不能太長。前綴的長度應該使前綴索引的選擇性接近索引整個列，即前綴的「基數」應該接近於完整列的「基數」。

舉例說明

　　下面的例子，查詢軟件名稱，並統計其數量

統計 #T

　　第一列的統計數量則可認爲是 #T，如今要查找到最頻繁出現（基數接近 #T ）的軟件名稱前綴，直接從 7 個前綴字母開始：

前綴長度爲 7 索引

　　每一個前綴都比原來的軟件名稱出現的次更多，所以惟一前綴比惟一軟件名稱要少得多。而後咱們增長前綴長度，直到這個前綴的選擇性接近完整列的選擇性，此時的前綴長度爲 9：

前綴長度爲 9 索引

　　試過 10，和 9 差很少，最後，選擇了前綴長度爲 9 的索引。 　　

　　個人博客地址：MySQL 高性能索引以前綴索引