2 创建联合索引_想进大厂，这些Mysql索引底层知识你是必须知道的
推薦學習
- 阿里P8MySQL，基礎/索引/鎖/日志/調優都不誤，一鍋深扒端給你
- 最新Java崗面試清單：分布式+Dubbo+線程+Redis+數據庫+JVM+并發
前言
這一篇是講解Mysql中做使用到的「索引的種類」，「索引正確使用的原則」、「怎么優化索引」、「以及兩種存儲引擎InnoDB和MyISAM索引的數據布局原理」。
索引種類
在說索引之前，我們先來說一說什么是索引呢？對于索引個人的理解就是，索引是一種加快查詢數據的數據結構。
所以，索引就是一種數據結構，作用就是發揮這種數據結構的作用，加快查詢的效率，例如：InnoDB存儲引擎中使用的是就是B+tree這種數據結構來組織索引。
Mysql中索引的種類也不是很多，不同類型的索引有不同的作用，索引的作用相互之間也存在交叉關系，Mysql中索引主要分為以下幾類：
若是你想查看一個表的所有索引，可以執行下面的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字段的索引排序才是完全有序的。
所以你會發現，在聯合索引中你只有使用以下的規則的方式查詢才會使用到索引：
因為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=5、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(非聚簇索引)」 有了非常清晰的認識和理解，下面是來說一說索引的優化，這個也是和我們日常開發最密切相關的。
索引原則和優化
要正確的使用索引，就要正確的創建索引，用索引正確的查詢，不要使索引失效，因此索引的涉及和優化的原則應該遵循下面的幾個原則：
總結
索引是我們工作經常會使用到的數據查詢方式，正確的使用索引可以大大提高查詢的效率。
但是索引也不是十全十美的，也有自己的缺點，不正確的使用索引，將會導致索引大量的占據空間，索引并非是越多越好，索引文件會越發的膨脹，這樣嚴重的影響查詢的性能。
對于插入、更新 、刪除數據，除了維護數據以外，還要維護索引文件，這樣也會影響這些操作的性能，但是對于查詢的頻率遠高于更新和插入數據的業務場景，索引是再適合不過了
作者：公眾號非科班的科班
原文鏈接：https://juejin.im/post/5ef73e5b5188252e9631184e
總結
以上是生活随笔為你收集整理的2 创建联合索引_想进大厂，这些Mysql索引底层知识你是必须知道的的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 链路追踪_springcloud-第九回
- 下一篇： 原理图元件有波浪线_电气原理图和接线图识