MySQL實戰45講學習筆記：第十一講

1、如何在郵箱這樣的字段上創建合理的索引

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

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

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 這個字段上沒有索引，那麼這個語句就只能作全表掃描。

2、直接建立完整索引，這樣可能比較佔用空間

同時，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執行順序是這樣的：

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

• 1. 從 index1 索引樹找到知足索引值是’zhangssxyz@xxx.com’的這條記錄，取得 ID2的值；
• 2. 到主鍵上查到主鍵值是 ID2 的行，判斷 email 的值是正確的，將這行記錄加入結果集；
• 3. 取 index1 索引樹上剛剛查到的位置的下一條記錄，發現已經不知足email='zhangssxyz@xxx.com’的條件了，循環結束。

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

二、若是使用的是 index2執行順序是這樣的：

若是使用的是 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。

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

前面咱們說了使用前綴索引可能會增長掃描行數，這會影響到性能。其實，前綴索引的影響不止如此，咱們再看一下另一個場景。
你先來看看這個 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 索引再查一下，由於系統並不肯定前綴索引的定義是否截斷了完整信息。

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

3、其餘方式

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

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

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

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

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

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

一、第一種方式是使用倒序存儲

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

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

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

二、第二種方式是使用 hash 字段

第二種方式是使用 hash 字段。你能夠在表上再建立一個整數字段，來保存身份證的校驗碼，同時在這個字段上建立索引。

mysql> select field_list from t where id_card_crc=crc32('input_id_card_string') and id_card='input_id_card_string'

而後每次插入新記錄的時候，都同時用 crc32() 這個函數獲得校驗碼填到這個新字段。因爲校驗碼可能存在衝突，也就是說兩個不一樣的身份證號經過 crc32() 函數獲得的結果可能
是相同的，因此你的查詢語句 where 部分要判斷 id_card 的值是否精確相同

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

三、使用倒序存儲和使用 hash 字段這兩種方法的異同點。

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

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

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

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

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

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

4、小結

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

1. 直接建立完整索引，這樣可能比較佔用空間；
2. 建立前綴索引，節省空間，但會增長查詢掃描次數，而且不能使用覆蓋索引；
3. 倒序存儲，再建立前綴索引，用於繞過字符串自己前綴的區分度不夠的問題；
4. 建立 hash 字段索引，查詢性能穩定，有額外的存儲和計算消耗，跟第三種方式同樣，都不支持範圍掃描。

在實際應用中，你要根據業務字段的特色選擇使用哪一種方式。好了，又到了最後的問題時間。

若是你在維護一個學校的學生信息數據庫，學生登陸名的統一格式是」學號@gmail.com", 而學號的規則是：十五位的數字，其中前三位是所在城市編號、第四到第
六位是學校編號、第七位到第十位是入學年份、最後五位是順序編號。系統登陸的時候都須要學生輸入登陸名和密碼，驗證正確後才能繼續使用系統。就只考慮
登陸驗證這個行爲的話，你會怎麼設計這個登陸名的索引呢？

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

5、上期問題時間

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

https://time.geekbang.org/45ba9ec1-70fa-4ab0-baa0-61b4537cc25e

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

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

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

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

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

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

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

6、精選留言

一、封建的風

 

二、某人

回答下今天老師的問題:1.在user創建索引,因爲學號的最後7位才能肯定到某個學生.不知足最左前綴,那麼select from where '%1234567%'沒法使用索引,是全表掃描。可是這種狀況也有優化的辦法,若是該表上的字段比較多,能夠這樣改寫select password from t join (select id from where user like '%1234567%') as a on a.id=t.id經過全掃描二級索引獲得惟一id值.再用id值與t表關聯的時候,就能迅速的定位到某一行了,避免全表掃描不過在本次問題裏,這種方式效果很差  2.hash索引,創建(hashuser,user,password)索引,不用回表,覆蓋索引,可是索引佔用長度長。或者創建(hashuser)索引,由於hashuser基本上能肯定到惟一值,雖然回表可是掃描的行數也就兩行,效率也挺高。可是hash索引對於insert和update操做要多作一些額外的操做。要嘛經過程序計算出hash值,插入表裏,要嘛就經過觸發器來作。3.創建前綴索引,因爲後面是固定email,能夠考慮只存學號.因爲學號後面7位就能肯定到某一個學生,能夠用倒序存儲+前綴索引。不過因爲前綴索引不能在int類型上創建,只能用varchar類型。雖然前綴索引沒法用到覆蓋索引,不過回表掃描的行數也就一行,效率也挺高。這種方式來講,對insert和update相對還好。還有前綴索引還有個影響是不能用於排序。