假設，你現在維護一個支援郵箱登入的系統，使用者表是這麼定義的：
create table SUser(
ID bigint unsigned primary key,
email varchar(64),
...
)engine=innodb;
由於要使用郵箱登入，所以業務程式碼中一定會出現類似於這樣的語句：
select f1, f2 from SUser where email='xxx';
如果 email 這個欄位上沒有索引，那麼這個語句就只能做全表掃描。
1）那我可以在郵箱地址這個欄位上面建索引嗎？
-
MySQL 是支援字首索引的，可以定義字串的一部分作為索引
2）如果建立索引的語句不指定字首長度，那麼會怎麼樣？
-
索引就會包含整個字串
3）能舉例來說明一下嗎？
alter table SUser add index index1(email);
或
alter table SUser add index index2(email(6));
-
index1 索引裡面，包含了每個記錄的整個字串
-
index2 索引裡面，對於每個記錄都是隻取前 6 個位元組
4）這兩種不同的定義在資料結構和儲存上有什麼區別呢？
明顯看出email(6) 這個索引結構佔用的空間會更小
5）email(6) 這個索引結構有什麼缺點嗎？
-
可能會增加額外的記錄掃描次數
6）下面這個語句，在這兩個索引定義下分別是怎麼執行的？
select id,name,email from SUser where email='zhangssxyz@xxx.com';
index1（即 email 整個字串的索引結構），執行順序
-
從 index1 索引樹找到滿足索引值是’zhangssxyz@xxx.com’的這條記錄，取得 ID2 的值；
-
回表查到主鍵值是 ID2 的行，判斷 email 的值是正確的，將這行記錄加入結果集；
-
繼續在index索引樹的下一條記錄，發現已經不滿足 email='zhangssxyz@xxx.com’的條件了，迴圈結束。
這個過程中，只需要回主鍵索引取一次資料，所以系統認為只掃描了一行。
index2（即 email(6) 索引結構），執行順序
-
從 index2 索引樹找到滿足索引值是’zhangs’的記錄，找到的第一個是 ID1；
-
到主鍵上查到主鍵值是 ID1 的行，判斷出 email 的值不是’zhangssxyz@xxx.com’，這行記錄丟棄；
-
取 index2 上剛剛查到的位置的下一條記錄，發現仍然是’zhangs’，取出 ID2，再到 ID 索引上取整行然後判斷，這次值對了，將這行記錄加入結果集；
-
重複上一步，直到在 idxe2 上取到的值不是’zhangs’時，迴圈結束。
在這個過程中，要回主鍵索引取 4 次資料，也就是掃描了 4 行。
7）通過上面的對比，能得出什麼結論？
-
使用字首索引後，可能會導致查詢語句讀資料的次數變多。
8）字首索引真的一無是處嗎？
-
如果我們定義的 index2 不是 email(6) 而是 email(7），那滿足字首’zhangss’的記錄只有一個，直接就查到 ID2了，只掃描一行就結束了。
9）那麼使用字首索引有哪些注意事項？
-
長度選擇合理
10）當要給字串建立字首索引時，我咋知道我該用多長的字首索引呢？
-
統計索引上有多少個不同的值來判斷要使用多長的字首。
11）怎樣統計索引上有多少個不同的值？
select count(distinct email) as L from SUser;
12）拿到了索引對應的有多少個不同的值之後下一步該做什麼？
-
依次選取不同長度的字首來看這個值
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; -
然後，在 L4~L7 中，找出第一個不小於 L * 95% 的值，說明通過這個索引可以找出百分之95以上的資料。
13）字首索引對覆蓋索引的影響是什麼？
下面這個 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 整個字串的索引結構）的話，查email的話就能得到ID，那就不用回表了，這個就是覆蓋索引。
-
用 index2（即 email(6) 索引結構）的話，就不得不回到 ID 索引再去判斷 email 欄位的值。
14）那我把index2 的定義修改為 email(18) 的字首索引不就行了？
-
這個18是你自己定義的，系統不知道18這個長度是否已經大於我的email長度，所以它還是會回表去查一下驗證。
總而言之：使用字首索引就用不上覆蓋索引對查詢效能的優化了
15）對於類似於郵箱這樣的欄位來說，使用字首索引的效果可能還不錯。但是，遇到身份證這種字首的區分度不夠好的情況時，我們要怎麼辦呢？
-
索引選取的要更長一些。
-
但是所以越長的話，佔的磁碟空間更大，相同的一頁能放下的索引值就變少了，反而會影響查詢效率。
-
16）如果我們能夠確定業務需求裡面只有按照身份證進行等值查詢的需求，還有沒有別的處理方法呢？
-
既然正過來相同的多，那我就把它倒過來存。查詢時候這樣查
select field_list from t where id_card = reverse('input_id_card_string');使用 的時候用count(distinct) 方法去做個驗證
-
使用 hash 欄位。在表上再建立一個整數字段，來儲存身份證的校驗碼，同時在這個欄位上建立索引。
alter table t add id_card_crc int unsigned, add index(id_card_crc);每次插入新記錄的時候，都同時用 crc32() 這個函式得到校驗碼填到這個新欄位。由於校驗碼可能存在衝突，也就是說兩個不同的身份證號通過 crc32() 函式得到的結果可能是相同的，所以你的查詢語句 where 部分要判斷 id_card 的值是否精確相同。
select field_list from t where id_card_crc=crc32('input_id_card_string') and id_card='input_id_card_string'這樣，索引的長度變成了 4 個位元組(int型別），比原來小了很多
17）使用倒序儲存和使用 hash 欄位這兩種方法有什麼異同點？
-
相同點：都不支援範圍查詢
-
倒序儲存的欄位上建立的索引是按照倒序字串的方式排序的，已經沒有辦法利用索引方式查出身份證號碼在[ID_X, ID_Y]的所有市民了。同樣地，hash 欄位的方式也只能支援等值查詢。
-
-
區別
-
從佔用的額外空間來看，倒序儲存方式在主鍵索引上，不會消耗額外的儲存空間，而 hash 欄位方法需要增加一個欄位。當然，倒序儲存方式使用 4 個位元組的字首長度應該是不夠的，如果再長一點，這個消耗跟額外這個 hash 欄位也差不多抵消了。
-
在 CPU 消耗方面，倒序方式每次寫和讀的時候，都需要額外呼叫一次 reverse 函式，而 hash 欄位的方式需要額外呼叫一次 crc32() 函式。如果只從這兩個函式的計算複雜度來看的話，reverse 函式額外消耗的 CPU 資源會更小些。
-
從查詢效率上看，使用 hash 欄位方式的查詢效能相對更穩定一些。因為 crc32 算出來的值雖然有衝突的概率，但是概率非常小，可以認為每次查詢的平均掃描行數接近 1。而倒序儲存方式畢竟還是用的字首索引的方式，也就是說還是會增加掃描行數。
-
案例：如果你在維護一個學校的學生資訊資料庫，學生登入名的統一格式是”學號 @gmail.com", 而學號的規則是：十五位的數字，其中前三位是所在城市編號、第四到第六位是學校編號、第七位到第十位是入學年份、最後五位是順序編號。
18）系統登入的時候都需要學生輸入登入名和密碼，驗證正確後才能繼續使用系統。就只考慮登入驗證這個行為的話，你會怎麼設計這個登入名的索引呢？
-
一個學校每年預估2萬新生，50年才100萬記錄，能節省多少空間，直接全欄位索引。省去了開發轉換及侷限性風險，碰到超大量迫不得已再用後兩種辦法
-
實際操作上直接全欄位索引就行了，一個學校資料庫的資料量和查詢壓力都不會大到哪兒去。 如果單從優化資料表的角度： \1. 字尾@gmail可以單獨一個欄位來存，或者用業務程式碼來保證， \2. 城市編號和學校編號估計也不會變，也可以用業務程式碼來配置 \3. 然後直接存年份和順序編號就行了，這個欄位可以全欄位索引