怎麼給字符串字段加索引？
- MySql實戰筆記是針對極客時間：《MySql實戰45講–從原理到實戰，丁奇帶你搞懂MySql》系列課程的學習和自我總結而成的讀書筆記；
一、歸納
1.1 字符串字段創建索引方式？
- 直接創建索引
- 創建前綴索引
- 倒序存儲，再創建前綴索引
- 創建 hash 字段索引
1.2 各種方式可能的缺點？
| 創建方式 | 優點 | 缺點 | 場景 |
|---|---|---|---|
| 直接創建索引 | 簡單 | 字符串很長可能佔用大量空間 | 一般場景 |
| 前綴索引 | 節約空間 | 不能索引覆蓋，可能損失精度增加掃描次數 | 字符串很長的場景 |
| 倒序存儲 | 解決字符串前綴相似度太高區分度低的問題 | 需要額外倒序計算，不能範圍查詢 | 前綴相似度高，比如身份證號 |
| hash字段索引 | 衝突更低 | 需要二外字段存儲hash值，不能範圍查詢 | 前後綴都相似的場景，比如一類名稱的郵箱 |
- 在使用前綴索引時，需要計算不同位的前綴和總記錄數量的佔比，得到能夠接受的精度損失。
- 倒序存儲和hash字段索引都是爲了解決相似前綴過長的問題，二者都不能範圍查詢，如果只有等值查詢的時候，可以考慮這兩種方案
二、原文
現在，幾乎所有的系統都支持郵箱登錄，如何在郵箱這樣的字段上建立合理的索引，是我們今天要討論的問題。
假設，你現在維護一個支持郵箱登錄的系統，用戶表是這麼定義的：
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 所示，就是這兩個索引的示意圖。
從圖中你可以看到，由於 email(6) 這個索引結構中每個郵箱字段都只取前 6 個字節（即：zhangs），所以佔用的空間會更小，這就是使用前綴索引的優勢。
但，這同時帶來的損失是，可能會增加額外的記錄掃描次數。
接下來，我們再看看下面這個語句，在這兩個索引定義下分別是怎麼執行的。
select id,name,email from SUser where email='[email protected]';
如果使用的是 index1（即 email 整個字符串的索引結構），執行順序是這樣的：
- 1.從 index1 索引樹找到滿足索引值是’[email protected]’的這條記錄，取得 ID2 的值；
- 2.到主鍵上查到主鍵值是 ID2 的行，判斷 email 的值是正確的，將這行記錄加入結果集；
- 3.取 index1 索引樹上剛剛查到的位置的下一條記錄，發現已經不滿足 email='[email protected]’的條件了，循環結束。
這個過程中，只需要回主鍵索引取一次數據，所以系統認爲只掃描了一行。
如果使用的是 index2（即 email(6) 索引結構），執行順序是這樣的：
- 1.從 index2 索引樹找到滿足索引值是’zhangs’的記錄，找到的第一個是 ID1；
- 2.到主鍵上查到主鍵值是 ID1 的行，判斷出 email 的值不是’[email protected]’，這行記錄丟棄；
- 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% 的值，假設這裏 L6、L7 都滿足，你就可以選擇前綴長度爲 6。
前綴索引對覆蓋索引的影響
前面我們說了使用前綴索引可能會增加掃描行數，這會影響到性能。其實，前綴索引的影響不止如此，我們再看一下另外一個場景。
你先來看看這個 SQL 語句：
select id,email from SUser where email='[email protected]';
與前面例子中的 SQL 語句
select id,name,email from SUser where email='[email protected]';
相比，這個語句只要求返回 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> 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 的值。
這個值的計算方法，我會在後面有文章爲你詳細講解。
