想進大廠，這些Mysql索引底層知識你是必須知道的。

前言

上一篇總結了Mysql的鎖機制，經過讀者的反映和閱讀量顯示，整體仍是不錯的，感興趣的能夠閱讀一下[]。

寫了那麼多的Mysql文章，有讀者問我是否是dba，工做真的須要掌握那麼深嗎。我想說的是：我是一名Java全職開發人員不是dba。

假如你只知足於平常的crud，你能夠放棄這些底層的知識，能夠沒必要學的那麼深，如果你想往高處走，這些底層的知識，是你必備的。

話很少說，這一篇總結是講解Mysql的索引，以前寫過一篇關於索引的，主要是講解索引的底層的數據結構B+tree。

這一篇是講解Mysql中作使用到的「索引的種類」，「索引正確使用的原則」、「怎麼優化索引」、「以及兩種存儲引擎InnoDB和MyISAM索引的數據佈局原理」。

索引種類

在說索引以前，咱們先來講一說什麼是索引呢？對於索引我的的理解就是，索引是一種加快查詢數據的數據結構。

因此，索引就是一種數據結構，做用就是發揮這種數據結構的做用，加快查詢的效率，例如：InnoDB存儲引擎中使用的是就是B+tree這種數據結構來組織索引。

Mysql中索引的種類也不是不少，不一樣類型的索引有不一樣的做用，索引的做用相互之間也存在交叉關係，Mysql中索引主要分爲如下幾類：

1. 「主鍵索引」（ PRIMARY KEY）：主鍵索引通常都是在建立表的時候指定， 「一個表只有一個主鍵索引」，特色是 「惟1、非空」。
2. 「惟一索引」（ UNIQUE）：惟一索引具備的特色就是惟一性，能夠在建立表的時候指定，也能夠在建立表後建立。
3. 「普通索引」（ INDEX）：普通索引惟一的做用就是加快查詢。
4. 「組合索引」（ INDEX）：組合索引是建立一個 「多個字段的索引」，這個概念是相對於上上面的單列索引而言，組合索引查詢遵循 「最左前綴原則」。
5. 「全文索引」（ FULLTEXT）：全文索引是針對一些大的 「文本字段」建立的索引，也稱爲 「全文檢索」。
6. 「聚簇索引」和 「非聚簇索引」：聚簇索引和非聚簇索引的概念比上面的概念要大，屬於包含和被包含的關係。例如：InnoDB中主鍵索引使用的就是聚簇索引。

如果你想查看一個表的全部索引，能夠執行下面的sql來查看：

show index from 表名
複製代碼

例如，查看我本身的測試表裏面的索引，以下圖所示，Key_name表示索引的名字，Column_name表示索引的字段。

上面大概的說了主要索引的概念，下面詳細的介紹一下這幾大索引的特色和使用。

主鍵索引

主鍵索引在InnoDB存儲引擎中是最多見的索引類型，一個表都會有一個主鍵索引，它索引的字段不容許爲空值，而且惟一。

通常是在建立表的時候，能夠經過RIMARY KEY指定主鍵索引，在InnoDB存儲引擎中，如果建立表的時候沒有主觀建立主鍵索引，Mysql就會看錶中是否有惟一索引，有，就會指定「非空的惟一索引」爲主鍵索引；

沒有，就會默認生成一個6byte空間的自動增加主鍵做爲主鍵索引，能夠經過select _rowid from 表名查詢的是對應的主鍵值.。

MyISAM儲存引擎是能夠不存在主鍵索引，MyISAM和InnoDB儲存數據的結構方式仍是有明顯的區別，這個後面篇章會詳細講解。

惟一索引

惟一索引與主鍵索引的區別就是，惟一索引容許爲空，如果在組合索引中，只要建立的列值是惟一的

惟一索引在實際中更多的是用來保證數據的惟一性，假如你僅僅要數據可以快速查詢，你也可使用普通索引，因此惟一索引重在體現它的惟一性。

實際的業務場景，有些庫表字段要求惟一，就可使用惟一索引，建立惟一索引的方式有三種。

（1）一個是在建立表的時候指定，以下sql：

CREATE TABLE user( 
 id INT PRIMARY KEY NOT NULL,  name VARCHAR(16) NOT NULL,  UNIQUE unique_name (name(10)) ); 複製代碼

（2）也能夠在表建立後建立，以下sql：

CREATE UNIQUE INDEX unique_name ON user(name(10))；
複製代碼

（3）經過修改表結構建立，以下sql：

ALTER user ADD UNIQUE unique_name ON (name(10))
複製代碼

這裏有一個細節要注意的是建立的name字段，指定的長度是16字符，而建立的索引的長度制定的是10字符，由於也沒有人的名字長度會超過10個字符，因此減小索引長度，可以減小索引所佔的空間的大小。

普通索引

普通索引的惟一做用就是加快數據的查詢，通常對查詢語句WHERE和ORDER BY後面的字段建立普通索引。

建立普通索引的方式也有三種，基本和建立惟一索引的方式同樣，只是把關鍵字UNIQUE換成INDEX，以下所示：

// 建立表的時候建立
CREATE TABLE user(  id INT PRIMARY KEY NOT NULL,  name VARCHAR(16) NOT NULL,  INDEX index_name (name(10)) ); // 建立表後建立 CREATE INDEX INDEX index_name ON user(name(10))； // 修改表結構建立 ALTER user ADD INDEX index_name ON (name(10)) 複製代碼

如果想刪除索引，能夠經過執行下面的sql進行刪除索引：

DROP INDEX index_name ON user;
複製代碼

組合索引

組合索引即用多個字段建立一個索引，組合索引可以避免「回表查詢」，相對於多字段的單列索引，組合索引的查詢效率更高。

建立組合索引(聯合索引)的方式和上面建立普通索引的方式同樣，只不過字段的數目多了，以下sql建立：

// 其它方式和上面的同樣，這裏就只列舉修改表結構的方式建立
ALTER TABLE employee ADD INDEX name_age_sex (name(10),age,sex); 複製代碼

回表查詢

什麼是回表查詢呢？回表查詢簡單來講「經過二級索引查詢數據，得不到完整的數據行，須要再次查詢主鍵索引來得到數據行」。

InnoDB存儲引擎中，索引分爲 「聚簇索引」和「二級索引」，主鍵索引就是聚簇索引，其它的索引爲二級索引。

聚簇索引中的葉子節點保存着完整的數據行，而二級索引的葉子節點並非保存完整的數據行。

上面提到InnoDB表是必定要有主鍵索引的，雖然索引佔據空間，可是索引符合二分查找的算法，查找數據很是的快。

假設仍是上面的employee表，裏面有主鍵索引id，和普通的索引name，那麼在InnoDB中就會存在兩棵B+Tree，一棵是主鍵索引樹：

主鍵索引樹

在主鍵索引樹中的葉子節點存儲的是完整的數據行，另一棵是name字段的二級索引樹，以下圖所示：

假若你執行這條sql：select name, age, sex from employee where id ='as';就會先執行二級索引的查詢，當查詢name='as'時，獲得主鍵爲50，再根據主鍵查詢主鍵索引樹，獲得完整的數據行，具體的執行流程以下：

回表原理圖

這個就是回表查詢，回表查詢會查詢兩次，這樣就會下降查詢的效率，爲了不回表查詢，只查詢一次就能獲得完整的數據呢？

索引覆蓋

常見的方式就是「創建組合索引（聯合索引）「進行」索引覆蓋」，什麼是索引覆蓋呢？索引覆蓋就是「索引的葉子節點已經包含了查詢的數據，不必再回表進行查詢。」

假如我仍是執行以下sql：select name, age, sex from employee where id ='as';由於普通索引只有name字段才創建了索引，這必然會致使回表查詢。

爲了提升查詢效率，就(name)「單列索引升級爲聯合索引」(name, age, sex)就不一樣了。

由於創建的聯合索引，在二級節點的葉子階段就會同時存在name, age, sex三個的值，一次性就會得到所須要的數據，這樣就避免了回表，可是全部的方案都不是完美的。

如果這個聯合索引哪一天某一個數據行的name值改變了或者age改變了，我就須要同時維護主鍵索引和聯合索引兩棵樹，這樣的維護成本就高了，性能開銷也大了。

相比以前數據的改變，我只須要維護主鍵索引便可，聯合索引的建立就致使了須要同時維護兩棵樹，這樣就會影響插入、更新數據的操做，因此並無哪一種方案是完美的。

最左前綴原則

咱們知道單列索引是按照索引列有序性的進行組織B+Tree結構的，聯合索引又是怎麼組織B+Tree呢？

聯合索引其實也是按照建立索引的時候，最左邊的進行最開始的排序，也就是「最左前綴原則」，好比一個表中有以下數據：

name	age	sex
ad	23	男
bc	21	男
bc	24	女
bc	25	男
de	21	女

如上圖所示，對於聯合索引中name字段是放在最前面的，因此name是徹底有序的，可是age字段就不是有序的，只有當name相同，例如：name='bc'此時age字段的索引排序纔是徹底有序的。

因此你會發現，在聯合索引中你只有使用如下的規則的方式查詢纔會使用到索引：

1. name,age,sex
2. name,age
3. name

由於Mysql的底層有查詢優化器，會判斷sql執行的時候如果使用全表掃描的效率比使用索引的效率更高，就會使用全表掃描。

假如，我查詢的時候使用age>=23,sex='男';兩個字段做爲查詢條件，可是沒有使用name字段，由於在name不知情的條件下，對於age是無序的。

對於age>=23條件可能在不少的name不一樣中都有符合條件的出現，因此就沒有辦法使用索引，這也是索引實現的緣由，必定要遵循「查找有序，充分的利用索引的有序性」。

假如你是分別在name，age，sex三個字段中分別創建三個單列索引，就至關於創建三顆索引樹，那麼它的查詢效率，比咱們使用一棵索引樹查詢效率就可想而知了。

有一種狀況即便使用到了最左邊的name字段也不會使用索引，例如：WHERE name like '%d%'；這種like條件的模糊查詢是會使索引失效。

咱們能夠這樣理解，「查詢字符串也是遵循最左前綴原則的」，字符串的查詢是對字符串裏面的字符一個一個的匹配，「如果字符串最左邊爲%表示一個不肯定的字符串，那麼是沒辦法利用到索引的有序性」。

可是如果修改成 ：WHERE name like 'd%'；就可使用索引，由於最左邊的字符串是肯定的，這種稱爲「匹配列前綴」。

實際業務場景中聯合索引的建立，「咱們應該把識別度比較高的字段放在前面，提升索引的命中率，充分的利用索引」。

索引下推

Mysql5.6版本提出了索引下推的原則，「用於查詢優化，主要是用於like關鍵字的查詢的優化」，什麼是索引下推呢？

下面經過演示來講明如下他的概念，仍是利用原來的employee測試表，假如我要執行下面的sql進行查詢：SELECT * from user where name like '張%' and age=40；

假如沒有索引下推，執行的過程以下圖所示：

查詢會直接忽略age字段，將name查詢的張開頭的id=五、id=7的結果返回給Mysql服務器，再執行兩次的回表查詢。

如果上面的查詢操做使用了索引下推，執行的過程以下：

Mysql會將查詢條件age=40的查詢條件傳遞給存儲引擎，再次過濾掉age=50的數據行，這樣回表的次數就變爲了一次，提升了查詢效率。

總結起來索引下推就是在執行sql查詢的時候，會將一部分的索引列的判斷條件傳遞給存儲引擎，由存儲引擎經過判斷是否符合條件，只有符合條件的數據纔會返回給Mysql服務器。

全文索引

全文索引也稱爲全文檢索，能夠經過如下sql創建全文索引：ALTER TABLE employee ADD FULLTEXT fulltext_name(name);或者CREATE INDEX的方式建立。

全文索引主要是針對CHAR、VARCHAR或TEXT這種文本類的字段有效，有人說不也可使用like關鍵字來查詢文本嗎。

普通索引（單列索引）的查詢只能加快字段內容中最前面的字符串的檢索，如果對於多個單詞組成文本的查詢普通索引就無能爲力了。

索引一經建立就沒有辦法修改，如果想要修改索引，必須重建，可使用如下sql來刪除索引：DROP INDEX fulltext_name ON employee;

聚簇索引和非聚簇索引

聚簇索引和非聚簇索引是相對於存儲引擎的概念，範圍比較大，包含上面所提到的索引類型。

「聚簇索引就是葉子節點中存儲的就是完整的行數據，索引和數據存儲在一塊兒；而非聚簇索引的索引文件和數據文件是分開的，因此查詢數據會多一次查詢」。

所以聚簇索引的查詢速度會快於非聚簇索引的查詢速度，再Mysql的村相互引擎中，「InnoDB支持聚簇索引，MyISAM不支持聚簇索引，MyISAM支持非聚簇索引」。

聚簇索引

下面咱們來看看InnoDB中的聚簇索引，前面說到InnoDB都會有一個主鍵，該主鍵就是用於支持聚簇索引，聚簇索引結構圖，大體以下圖所示：

InnoDB中適用於最好的主鍵選擇就是給出一個AUTO_INCREMENT的列做爲自增的主鍵，有的人可能會使用UUID做爲隨機主鍵。

由於索引要維持有序性，如果使用隨機的主鍵，主鍵的插入須要尋找合適的位置進行放置，這樣維護主鍵索引樹的成本就會便得更高。

相反的，自增主鍵，主鍵都是自增變大，在維護主鍵索引樹的成本就會變得更小，隨意應該儘可能避免隨機主鍵。

非聚簇索引

MyISAM使用的是非聚簇索引，新插入數據的時候，會按順序的寫入的磁盤中，而且給每一行數據標記一個行號，從小逐漸增大。

當MyISAM建立主鍵索引的時候，造成的主鍵索引樹的結構圖以下圖所示：

在主鍵索引中，數據也是非空且惟一，主鍵索引樹中存儲的是數據行的行號，當查詢數據的時候使用主鍵索引查詢須要查詢到行號，而後經過行號獲取數據。

非逐漸索引和主鍵索引同樣葉子節點也是存儲着行號，惟一的區別就是非逐漸索引不要求非空、惟一。

咱們能夠通對比圖來對比一下「InnoDB(聚簇索引)」 和 「MyISAM(非聚簇索引)」 的索引數據佈局，以下圖所示：

說到這裏相信應該你們對於「InnoDB(聚簇索引)」 和 「MyISAM(非聚簇索引)」 有了很是清晰的認識和理解，下面是來講一說索引的優化，這個也是和咱們平常開發最密切相關的。

索引原則和優化

要正確的使用索引，就要正確的建立索引，用索引正確的查詢，不要使索引失效，所以索引的涉及和優化的原則應該遵循下面的幾個原則：

1. 索引列不要在表達式中出現，這樣會致使索引失效。如： 「SELECT ...... WHERE id+1=5」;
2. 索引列不要做爲函數的參數使用。
3. 索引列儘可能不要使用like關鍵字。如： 「SELECT ...... WHERE name like '%d%'」;
4. 數字型的索引列不要看成字符串類型進行條件查詢。如： 「SELECT ...... WHERE id = '35'」;
5. 儘可能不要在條件NOT IN、<>、!= 中使用索引。
6. 在索引列的字段中不要出現NULL值，NULL值會使索引失效，能夠用特殊的字符好比空字符串' '或者0來代替NULL值。
7. 聯合索引的查詢應該遵循最左前綴原則。
8. 通常對於區別性比較大的字段創建索引，在聯合索引中區別性比較大（識別度比較高）放在最前面，提升索引的命中率。
9. 索引的大小要適度，不易過大，避免索引的冗餘。

總結

索引是咱們工做常常會使用到的數據查詢方式，正確的使用索引能夠大大提升查詢的效率。

1. 一方面索引減小了索引服務器須要掃描的數據行的數量，將原來的全表掃描，使用特定的數據結構，可以快速的定位數據行。
2. 另外一方面使用有序的索引，避免了排序，將原來的隨機的IO操做，變成了順序的IO操做，執行有序。

可是索引也不是十全十美的，也有本身的缺點，不正確的使用索引，將會致使索引大量的佔據空間，索引並不是是越多越好，索引文件會愈加的膨脹，這樣嚴重的影響查詢的性能。

對於插入、更新 、刪除數據，除了維護數據之外，還要維護索引文件，這樣也會影響這些操做的性能，可是對於查詢的頻率遠高於更新和插入數據的業務場景，索引是再適合不過了。