11 | 怎麼給字符串字段加索引？

如今，幾乎全部的系統都支持郵箱登陸，如何在郵箱這樣的字段上創建合理的索引，是咱們今天要討論的問題。

假設，你如今維護一個支持郵箱登陸的系統，用戶表是這麼定義的：

mysql> create table SUser(
ID bigint unsigned primary key,
email varchar(64), 
... 
)engine=innodb;

因爲要使用郵箱登陸，因此業務代碼中必定會出現相似於這樣的語句：

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

從第4和第5篇講解索引的文章中，咱們能夠知道，若是email這個字段上沒有索引，那麼這個語句就只能作全表掃描。

同時，MySQL是支持前綴索引的，也就是說，你能夠定義字符串的一部分做爲索引。默認地，若是你建立索引的語句不指定前綴長度，那麼索引就會包含整個字符串。

好比，這兩個在email字段上建立索引的語句：

mysql> alter table SUser add index index1(email);
或
mysql> alter table SUser add index index2(email(6));

第一個語句建立的index1索引裏面，包含了每一個記錄的整個字符串；而第二個語句建立的index2索引裏面，對於每一個記錄都是隻取前6個字節。

那麼，這兩種不一樣的定義在數據結構和存儲上有什麼區別呢？如圖2和3所示，就是這兩個索引的示意圖。

圖1 email 索引結構

圖2 email(6) 索引結構

從圖中你能夠看到，因爲email(6)這個索引結構中每一個郵箱字段都只取前6個字節（即：zhangs），因此佔用的空間會更小，這就是使用前綴索引的優點。

但，這同時帶來的損失是，可能會增長額外的記錄掃描次數。

接下來，咱們再看看下面這個語句，在這兩個索引定義下分別是怎麼執行的。

select id,name,email from SUser where email='zhangssxyz@xxx.com';

若是使用的是index1（即email整個字符串的索引結構），執行順序是這樣的：

1. 從index1索引樹找到知足索引值是’zhangssxyz@xxx.com’的這條記錄，取得ID2的值；

2. 到主鍵上查到主鍵值是ID2的行，判斷email的值是正確的，將這行記錄加入結果集；

3. 取index1索引樹上剛剛查到的位置的下一條記錄，發現已經不知足email='zhangssxyz@xxx.com’的條件了，循環結束。

這個過程當中，只須要回主鍵索引取一次數據，因此係統認爲只掃描了一行。

若是使用的是index2（即email(6)索引結構），執行順序是這樣的：

1. 從index2索引樹找到知足索引值是’zhangs’的記錄，找到的第一個是ID1；

2. 到主鍵上查到主鍵值是ID1的行，判斷出email的值不是’zhangssxyz@xxx.com’，這行記錄丟棄；

3. 取index2上剛剛查到的位置的下一條記錄，發現仍然是’zhangs’，取出ID2，再到ID索引上取整行而後判斷，此次值對了，將這行記錄加入結果集；

4. 重複上一步，直到在idxe2上取到的值不是’zhangs’時，循環結束。

在這個過程當中，要回主鍵索引取4次數據，也就是掃描了4行。

經過這個對比，你很容易就能夠發現，使用前綴索引後，可能會致使查詢語句讀數據的次數變多。

可是，對於這個查詢語句來講，若是你定義的index2不是email(6)而是email(7），也就是說取email字段的前7個字節來構建索引的話，即知足前綴’zhangss’的記錄只有一個，也可以直接查到ID2，只掃描一行就結束了。

也就是說使用前綴索引，定義好長度，就能夠作到既節省空間，又不用額外增長太多的查詢成本。

因而，你就有個問題：當要給字符串建立前綴索引時，有什麼方法可以肯定我應該使用多長的前綴呢？

實際上，咱們在創建索引時關注的是區分度，區分度越高越好。由於區分度越高，意味着重複的鍵值越少。所以，咱們能夠經過統計索引上有多少個不一樣的值來判斷要使用多長的前綴。

首先，你可使用下面這個語句，算出這個列上有多少個不一樣的值：

mysql> select count(distinct email) as L from SUser;

而後，依次選取不一樣長度的前綴來看這個值，好比咱們要看一下4~7個字節的前綴索引，能夠用這個語句：

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;

固然，使用前綴索引極可能會損失區分度，因此你須要預先設定一個能夠接受的損失比例，好比5%。而後，在返回的L4~L7中，找出不小於 L * 95%的值，假設這裏L六、L7都知足，你就能夠選擇前綴長度爲6。

前綴索引對覆蓋索引的影響

前面咱們說了使用前綴索引可能會增長掃描行數，這會影響到性能。其實，前綴索引的影響不止如此，咱們再看一下另一個場景。

你先來看看這個SQL語句：

select id,email from SUser where email='zhangssxyz@xxx.com';

與前面例子中的SQL語句

select id,name,email from SUser where email='zhangssxyz@xxx.com';

相比，這個語句只要求返回id和email字段。

因此，若是使用index1（即email整個字符串的索引結構）的話，能夠利用覆蓋索引，從index1查到結果後直接就返回了，不須要回到ID索引再去查一次。而若是使用index2（即email(6)索引結構）的話，就不得不回到ID索引再去判斷email字段的值。

即便你將index2的定義修改成email(18)的前綴索引，這時候雖然index2已經包含了全部的信息，但InnoDB仍是要回到id索引再查一下，由於系統並不肯定前綴索引的定義是否截斷了完整信息。

也就是說，使用前綴索引就用不上覆蓋索引對查詢性能的優化了，這也是你在選擇是否使用前綴索引時須要考慮的一個因素。

其餘方式

對於相似於郵箱這樣的字段來講，使用前綴索引的效果可能還不錯。可是，遇到前綴的區分度不夠好的狀況時，咱們要怎麼辦呢？

好比，咱們國家的身份證號，一共18位，其中前6位是地址碼，因此同一個縣的人的身份證號前6位通常會是相同的。

假設你維護的數據庫是一個市的公民信息系統，這時候若是對身份證號作長度爲6的前綴索引的話，這個索引的區分度就很是低了。

按照咱們前面說的方法，可能你須要建立長度爲12以上的前綴索引，纔可以知足區分度要求。

可是，索引選取的越長，佔用的磁盤空間就越大，相同的數據頁能放下的索引值就越少，搜索的效率也就會越低。

那麼，若是咱們可以肯定業務需求裏面只有按照身份證進行等值查詢的需求，還有沒有別的處理方法呢？這種方法，既能夠佔用更小的空間，也能達到相同的查詢效率。

答案是，有的。

第一種方式是使用倒序存儲。若是你存儲身份證號的時候把它倒過來存，每次查詢的時候，你能夠這麼寫：

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

因爲身份證號的最後6位沒有地址碼這樣的重複邏輯，因此最後這6位極可能就提供了足夠的區分度。固然了，實踐中你不要忘記使用count(distinct)方法去作個驗證。

第二種方式是使用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'

這樣，索引的長度變成了4個字節，比原來小了不少。

接下來，咱們再一塊兒看看使用倒序存儲和使用hash字段這兩種方法的異同點。

首先，它們的相同點是，都不支持範圍查詢。倒序存儲的字段上建立的索引是按照倒序字符串的方式排序的，已經沒有辦法利用索引方式查出身份證號碼在[ID_X, ID_Y]的全部市民了。一樣地，hash字段的方式也只能支持等值查詢。

它們的區別，主要體如今如下三個方面：

1. 從佔用的額外空間來看，倒序存儲方式在主鍵索引上，不會消耗額外的存儲空間，而hash字段方法須要增長一個字段。固然，倒序存儲方式使用4個字節的前綴長度應該是不夠的，若是再長一點，這個消耗跟額外這個hash字段也差很少抵消了。

2. 在CPU消耗方面，倒序方式每次寫和讀的時候，都須要額外調用一次reverse函數，而hash字段的方式須要額外調用一次crc32()函數。若是隻從這兩個函數的計算複雜度來看的話，reverse函數額外消耗的CPU資源會更小些。

3. 從查詢效率上看，使用hash字段方式的查詢性能相對更穩定一些。由於crc32算出來的值雖然有衝突的機率，可是機率很是小，能夠認爲每次查詢的平均掃描行數接近1。而倒序存儲方式畢竟仍是用的前綴索引的方式，也就是說仍是會增長掃描行數。

小結

在今天這篇文章中，我跟你聊了聊字符串字段建立索引的場景。咱們來回顧一下，你可使用的方式有：

1. 直接建立完整索引，這樣可能比較佔用空間；

2. 建立前綴索引，節省空間，但會增長查詢掃描次數，而且不能使用覆蓋索引；

3. 倒序存儲，再建立前綴索引，用於繞過字符串自己前綴的區分度不夠的問題；

4. 建立hash字段索引，查詢性能穩定，有額外的存儲和計算消耗，跟第三種方式同樣，都不支持範圍掃描。

在實際應用中，你要根據業務字段的特色選擇使用哪一種方式。

好了，又到了最後的問題時間。

若是你在維護一個學校的學生信息數據庫，學生登陸名的統一格式是」學號@gmail.com", 而學號的規則是：十五位的數字，其中前三位是所在城市編號、第四到第六位是學校編號、第七位到第十位是入學年份、最後五位是順序編號。

系統登陸的時候都須要學生輸入登陸名和密碼，驗證正確後才能繼續使用系統。就只考慮登陸驗證這個行爲的話，你會怎麼設計這個登陸名的索引呢？

你能夠把你的分析思路和設計結果寫在留言區裏，我會在下一篇文章的末尾和你討論這個問題。感謝你的收聽，也歡迎你把這篇文章分享給更多的朋友一塊兒閱讀。

上期問題時間

上篇文章中的第一個例子，評論區有幾位同窗說沒有復現，你們要檢查一下隔離級別是否是RR（Repeatable Read，可重複讀），建立的表t是否是InnoDB引擎。我把復現過程作成了一個視頻，供你參考。

在上一篇文章最後，我給你留的問題是，爲何通過這個操做序列，explain的結果就不對了？這裏，我來爲你分析一下緣由。

delete 語句刪掉了全部的數據，而後再經過call idata()插入了10萬行數據，看上去是覆蓋了原來的10萬行。

可是，session A開啓了事務並無提交，因此以前插入的10萬行數據是不能刪除的。這樣，以前的數據每一行數據都有兩個版本，舊版本是delete以前的數據，新版本是標記爲deleted的數據。

這樣，索引a上的數據其實就有兩份。

而後你會說，不對啊，主鍵上的數據也不能刪，那沒有使用force index的語句，使用explain命令看到的掃描行數爲何仍是100000左右？（潛臺詞，若是這個也翻倍，也許優化器還會認爲選字段a做爲索引更合適）

是的，不過這個是主鍵，主鍵是直接按照表的行數來估計的。而表的行數，優化器直接用的是show table status的值。

這個值的計算方法，我會在後面有文章爲你詳細講解。