如何構建高效能MySQL索引
介紹
上一篇文章中介紹了MySQL的索引基本原理以及常見的索引種類，這邊文章的重點在於如何構建一個高效能的MySQL索引，從中你可以學到如何分析一個索引是不是好索引，以及如何構建一個好的索引。
索引誤區
多列索引
一個索引的常見誤區是為每一列建立一個索引，如下面建立的索引：
CREATE TABLE `t` ( `c1` varchar(50) DEFAULT NULL, `c2` varchar(50) DEFAULT NULL, `c3` varchar(50) DEFAULT NULL, KEY `c1` (`c1`), KEY `c2` (`c2`), KEY `c3` (`c3`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
t表裡有三列，並且為每列建立了一個索引。建立索引的人為了能夠快速訪問表中的任何一列，因此為每一列添加了一個單獨的索引。在多個列上建立索引通常並不能很好的提高MySQL查詢效能，雖然說MySQL 5.0之後引入了索引合併策略，可以將多個單列索引合併成一個索引，但這並不總是有效的。同時建立多個索引的時候還會增加資料插入的成本，在插入資料的時候需要同時維護多個索引的寫入操作。
索引的計算
看下面這條sql語句：
select name from student where id + 1 = 5
即使我們在student表的id列上建立索引，上面的這條SQL語句也無法使用索引。SQL語句中索引欄位不能是表示式的一部分，也不能是函式的引數。
索引的長度以及選擇性
儘量不要在一個很長的列上使用索引，否則會導致索引佔用的空間很大，同時在進行資料的插入和更新的時候意味著更慢的速度。因此使用uuid列作為索引並不是一個好的選擇。從上一篇文章中我們可以知道，為了加快資料的訪問索引是需要常駐記憶體的，假如說我們把64位uuid作為索引，那麼隨著表中資料量的增加索引的大小也在急劇增加。同時因為uuid並沒有順序性，因此在資料插入的時候都需要從根節點找到當前索引的插入位置，如果同一個節點中的索引大小達到上限，還會導致節點分裂，更加降低了插入速度。
建立索引另外一個需要考慮的是索引的選擇性，通常情況下我們會使用選擇性高的列作為索引，但是也不一定一直是這樣，下一節會介紹如何權衡索引的選擇性。
建立高效能索引
選擇正確的索引順序
在選擇索引的順序的時候有一個原則：將索引選擇性最高的列放在左側，同時索引的順序要與查詢索引的順序一致，並且要兼顧考慮排序和分組的需要。在一個多列B樹多列中索引的順序意味著索引首先按照最左側的列進行排序，其次是第二列。所以無論是where語句還是order by語句都需要儘量滿足這個順序，這樣才能更好的使用索引。
索引的選擇性
列的選擇性高的含義是通過這一列能夠更多的過濾掉無用的資料，舉個極端的例子，如果把自增id建成索引那麼它的選擇性是最高的，因為會把無用的資料都過濾掉，只會剩下一條有效資料。我們可以通過下面的方式來簡單衡量某一個列的選擇性：
select count(distinct columnA)/count(*) as selectivity from table
當上面的資料越大的時候意味著columnA的選擇性越高。這種方式提供了一個衡量平均選擇性的辦法，但是也不一定是有效的，需要具體情況具體分析。
字首索引
當遇到特別長的列，但又必須要建立索引的時候可以考慮建立字首索引。字首索引的含義是把某一列的前N個字元作為索引，建立字首索引的方式如下：
alter table test add key(columnA(5));
上面這個語句就是把columnA的前5個字元建立為字首索引。字首索引是一種使索引更小、更快的有效辦法。但是字首所有有一個缺點：MySQL無法使用字首索引來做order by和group by，也無法使用字首索引做覆蓋掃描。
聚簇索引和非聚簇索引
聚簇索引
聚簇索引代表一種資料的儲存方式，表示同一個結構中儲存了B-Tree索引和資料行。也就是說當建立聚簇索引的時候實際的資料行存放在索引的葉子節點上。這也決定了每個表只能有一個聚簇索引。
聚簇索引組織資料的方式如下圖所示：
從圖中可以看到索引的葉子節點和資料行是存放在一起的，這樣的好處是可以直接讀取到資料行。在建立表的時候如果我們不顯式指定聚簇索引，那麼MySQL將會按照下面的邏輯來選擇聚簇索引：首先會通過主鍵列來聚集資料，如果沒有主鍵列那麼會選擇唯一的非空索引來替代。如果還沒有這樣的索引那麼會隱式的建立一個主鍵列來作為聚簇索引。
聚簇索引優點：
1、相關資料存放在一起，檢索的時候降低IO的次數
2、資料訪問更快
3、使用覆蓋索引掃描的查詢可以直接使用節點中的主鍵值
在使用上面的優點的時候聚簇索引也有一定的缺點：
1、聚簇索引將資料聚集在一起限制了插入速度，插入速度比較依賴於主鍵的順序
2、更新索引的時候代價會變高
3、二級索引的訪問的時候需要查詢兩次
非聚簇索引
非聚簇索引通常被稱為二級索引，與聚簇索引的不同在於，非聚簇索引的葉子節點存放的是資料的行指標或者是一個主鍵值。這樣在查詢資料的時候首先定位到葉子節點上的主鍵值(或者行指標)，然後通過主鍵值再到聚簇索引中查詢到對應的資料。從中我們可以看到對於非聚簇索引的查詢需要走兩次索引。下圖是一個非聚簇索引：
這個索引是InnoDB中的耳機索引，葉子節點中儲存的是索引和主鍵。對於MyISAM葉子節點儲存的是索引和行指標。
覆蓋索引
如果一個索引包含或者說覆蓋所有需要查詢的欄位的值，那麼就稱為覆蓋索引。覆蓋索引可以極大的提高查詢的效率，如果我們的查詢中只查詢索引，而不用去回表那應該最好不過了。
通常我們使用explain關鍵字來檢視一個查詢語句的執行計劃，通過執行計劃我們可以瞭解到查詢的細節。如果是覆蓋索引，我們會看到執行計劃的Extra列裡有”Using Index”的資訊。在查詢語句中一般我們希望是where條件中的語句儘量能被覆蓋，並且順序要跟索引的保持一致。還有一個需要注意的點是MySQL不能在索引中使用like操作，這樣會導致後面的索引失效。
後記
本文主要講了幾種索引的原理以及如何構建一個高效能的索引。索引的優先是一個漸進的過程，隨著資料量和查詢語句的不同而發生變化，重要的是瞭解索引的原理，這樣做出正確的優化。下一篇文章中將會介紹explain關鍵字，教你如何來看執行計劃，以及如何判斷一個查詢語句是否需要優化的。
----------------------------------------------------------------
歡迎關注我的微信公眾號：yunxi-talk，分享Java乾貨，進階Java程式設計師必備。
