深刻理解MySQL索引

前言

當提到MySQL數據庫的時候，咱們的腦海裏會想起幾個關鍵字：索引、事務、數據庫鎖等等，索引是MySQL的靈魂，是平時進行查詢時的利器，也是面試中的重中之重。

可能你瞭解索引的底層是b+樹，會加快查詢，也會在表中創建索引，但這是遠遠不夠的，這裏列舉幾個索引常見的面試題：

一、索引爲何要用b+樹這種數據結構？

二、彙集索引和非彙集索引的區別？

三、索引何時會失效，最左匹配原則是什麼？

當遇到這些問題的時候，可能會發現本身對索引仍是隻知其一;不知其二，今天咱們一塊兒學習MySQL的索引。

1、一條查詢語句是如何執行的

首先來看在MySQL數據庫中，一條查詢語句是如何執行的，索引出如今哪一個環節，起到了什麼做用。

1.1 應用程序發現SQL到服務端

當執行SQL語句時，應用程序會鏈接到相應的數據庫服務器，而後服務器對SQL進行處理。

1.2 查詢緩存

接着數據庫服務器會先去查詢是否有該SQL語句的緩存，key是查詢的語句，value是查詢的結果。若是你的查詢可以直接命中，就會直接從緩存中拿出value來返回客戶端。

注：查詢不會被解析、不會生成執行計劃、不會被執行。

1.3 查詢優化處理，生成執行計劃

若是沒有命中緩存，則開始第三步。

• 解析SQL：生成解析樹，驗證關鍵字如select,where,left join 等）是否正確。
• 預處理：進一步檢查解析樹是否合法，如檢查數據表和列是否存在，驗證用戶權限等。
• 優化SQL：決定使用哪一個索引，或者在多個表相關聯的時候決定表的鏈接順序。緊接着，將SQL語句轉成執行計劃。

1.4 將查詢結果返回客戶端

最後，數據庫服務器將查詢結果返回給客戶端。(若是查詢能夠緩存，MySQL也會將結果放到查詢緩存中)

這就是一條查詢語句的執行流程，能夠看到索引出如今優化SQL的流程步驟中，接下來了解索引究竟是什麼？

2、索引概述

先簡單地瞭解一下索引的基本概念。

2.1 索引是什麼

索引是幫助數據庫高效獲取數據的數據結構。

2.2 索引的分類

1）從存儲結構上來劃分

• Btree索引（B+tree，B-tree)
• 哈希索引
• full-index全文索引
• RTree

2）從應用層次上來劃分

• 普通索引：即一個索引只包含單個列，一個表能夠有多個單列索引。
• 惟一索引：索引列的值必須惟一，但容許有空值。
• 複合索引：一個索引包含多個列。

3）從表記錄的排列順序和索引的排列順序是否一致來劃分

• 彙集索引：表記錄的排列順序和索引的排列順序一致。
• 非彙集索引：表記錄的排列順序和索引的排列順序不一致。

2.3 彙集索引和非彙集索引

1）簡單歸納

• 彙集索引：就是以主鍵建立的索引。
• 非彙集索引：就是以非主鍵建立的索引（也叫作二級索引）。

2）詳細歸納

• 彙集索引

彙集索引表記錄的排列順序和索引的排列順序一致，因此查詢效率快，由於只要找到第一個索引值記錄，其他的連續性的記錄在物理表中也會連續存放，一塊兒就能夠查詢到。

缺點：新增比較慢，由於爲了保證表中記錄的物理順序和索引順序一致，在記錄插入的時候，會對數據頁從新排序。

• 非彙集索引

索引的邏輯順序與磁盤上行的物理存儲順序不一樣，非彙集索引在葉子節點存儲的是主鍵和索引列，當咱們使用非彙集索引查詢數據時，須要拿到葉子上的主鍵再去表中查到想要查找的數據。這個過程就是咱們所說的回表。

3）彙集索引和非彙集索引的區別

• 彙集索引在葉子節點存儲的是表中的數據。
• 非彙集索引在葉子節點存儲的是主鍵和索引列。

舉個例子

好比漢語字典，想要查「阿」字，只須要翻到字典前幾頁，a開頭的位置，接着「啊」「愛」都會出來。也就是說，字典的正文部分自己就是一個目錄，不須要再去查其餘目錄來找到須要找的內容。咱們把這種正文內容自己就是一種按照必定規則排列的目錄稱爲==彙集索引==。

若是遇到不認識的字，只能根據「偏旁部首」進行查找，而後根據這個字後的頁碼直接翻到某頁來找到要找的字。但結合部首目錄和檢字表而查到的字的排序並非真正的正文的排序方法。

好比要查「玉」字，咱們能夠看到在查部首以後的檢字表中「玉」的頁碼是587頁，而後是珏，是251頁。很顯然，在字典中這兩個字並無挨着，如今看到的連續的「玉、珏、瑩」三字實際上就是他們在非彙集索引中的排序，是字典正文中的字在非彙集索引中的映射。咱們能夠經過這種方式來找到所須要的字，但它須要兩個過程，先找到目錄中的結果，而後再翻到結果所對應的頁碼。咱們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱爲==非彙集索引==。

2.4 MySQL如何添加索引

1）添加PRIMARY KEY（主鍵索引）

ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )

2）添加UNIQUE（惟一索引）

ALTER TABLE `table_name` ADD UNIQUE (`column`)

3）添加INDEX（普通索引）

ALTER TABLE `table_name` ADD INDEX index_name (`column` )

4）添加FULLTEXT（全文索引）

ALTER TABLE `table_name` ADD FULLTEXT (`column`)

5）添加多列索引

ALTER TABLE `table_name` ADD INDEX index_name (`column1`,`column2`,`column3`)

3、索引底層數據結構

瞭解了索引的基本概念後，可能最好奇的就是索引的底層是怎麼實現的呢？爲何索引能夠如此高效地進行數據的查找？如何設計數據結構能夠知足咱們的要求？
下文經過通常程序員的思惟來想一下若是是咱們來設計索引，要如何設計來達到索引的效果。

3.1 哈希索引

可能直接想到的就是用哈希表來實現快速查找，就像咱們平時用的hashmap同樣，value = get(key) O(1)時間複雜度一步到位，確實，哈希索引是一種方式。

1）定義

哈希索引就是採用必定的哈希算法，只需一次哈希算法便可馬上定位到相應的位置，速度很是快。本質上就是把鍵值換算成新的哈希值，根據這個哈希值來定位。

2）侷限性

• 哈希索引沒辦法利用索引完成排序。
• 不能進行多字段查詢。
• 在有大量重複鍵值的狀況下，哈希索引的效率也是極低的（出現哈希碰撞問題）。
• 不支持範圍查詢。

在MySQL經常使用的InnoDB引擎中，仍是使用B+樹索引比較多。InnoDB是自適應哈希索引的（hash索引的建立由==InnoDB存儲引擎自動優化建立==，咱們干預不了）。

3.2 如何設計索引的數據結構呢

假設要查詢某個區間的數據，咱們只須要拿到區間的起始值，而後在樹中進行查找。

如數據爲：

1）查詢[7,30]區間的數據

當查找到起點節點10後，再順着鏈表進行遍歷，直到鏈表中的節點數據大於區間的終止值爲止。全部遍歷到的數據，就是符合區間值的全部數據。

2）還能夠怎麼優化呢？

利用二叉查找樹，區間查詢的功能已經實現了。可是，爲了節省內存，咱們只能把樹存儲在硬盤中。

那麼，每一個節點的讀取或者訪問，都對應一次硬盤IO操做。每次查詢數據時磁盤IO操做的次數，也叫作==IO漸進複雜度==，也就是==樹的高度==。

因此，咱們要減小磁盤IO操做的次數，也就是要==下降樹的高度==。

結構優化過程以下圖所示：

這裏將二叉樹變爲了M叉樹，下降了樹的高度，那麼這個M應該選擇多少才合適呢？

問題：對於相同個數的數據構建m叉樹索引，m叉樹中的m越大，那樹的高度就越小，那m叉樹中的m是否是越大越好呢？到底多大才合適呢？

無論是內存中的數據仍是磁盤中的數據，操做系統都是按頁（一頁的大小一般是4kb，這個值能夠經過getconfig(PAGE_SIZE)命令查看）來讀取的，一次只會讀取一頁的數據。

若是要讀取的數據量超過了一頁的大小，就會觸發屢次IO操做。因此在選擇m大小的時候，要儘可能讓每一個節點的大小等於一個頁的大小。

通常實際應用中，出度d（樹的分叉數）是很是大的數字，一般超過100；==樹的高度（h）很是小，一般不超過3==。

3.3 B樹

順着解決問題的思路知道了咱們想要的數據結構是什麼。目前索引經常使用的數據結構是B+樹，先介紹一下什麼是B樹（也就是B-樹）。

1）B樹的特色：

• 關鍵字分佈在整棵樹的全部節點。
• 任何一個關鍵字出現且只出如今一個節點中。
• 搜索有可能在非葉子節點結束。
• 其搜索性能等價於在關鍵字全集內作一次二分查找。

以下圖所示：

3.4 B+樹

瞭解了B樹，再來看一下B+樹，也是MySQL索引大部分狀況所使用的數據結構。

1）B+樹基本特色

• 非葉子節點的子樹指針與關鍵字個數相同。
• 非葉子節點的子樹指針P[i]，指向關鍵字屬於 [k[i],K[i+1])的子樹（注意：區間是前閉後開)。
• 爲全部葉子節點增長一個鏈指針。
• 全部關鍵字都在葉子節點出現。

這些基本特色是爲了知足如下的特性。

2）B+樹的特性

• 全部的關鍵字都出如今葉子節點的鏈表中，且鏈表中的關鍵字是有序的。
• 搜索只在葉子節點命中。
• 非葉子節點至關因而葉子節點的索引層，葉子節點是存儲關鍵字數據的數據層。

3）相對B樹，B+樹作索引的優點

• B+樹的磁盤讀寫代價更低。B+樹的內部沒有指向關鍵字具體信息的指針，因此其內部節點相對B樹更小，若是把全部關鍵字存放在同一塊盤中，那麼盤中所能容納的關鍵字數量也越多，一次性讀入內存的須要查找的關鍵字也就越多，相應的，IO讀寫次數就下降了。
• 樹的查詢效率更加穩定。B+樹全部數據都存在於葉子節點，全部關鍵字查詢的路徑長度相同，每次數據的查詢效率至關。而B樹可能在非葉子節點就中止查找了，因此查詢效率不夠穩定。
• B+樹只須要去遍歷葉子節點就能夠實現整棵樹的遍歷。

3.5 MongoDB的索引爲何選擇B樹，而MySQL的索引是B+樹？

由於MongoDB不是傳統的關係型數據庫，而是以Json格式做爲存儲的NoSQL非關係型數據庫，目的就是高性能、高可用、易擴展。擺脫了關係模型，因此範圍查詢和遍歷查詢的需求就沒那麼強烈了。

3.6 MyISAM存儲引擎和InnoDB的索引有什麼區別

1）MyISAM存儲引擎

• 主鍵索引

MyISAM的索引文件（.MYI）和數據文件（.MYD）文件是分離的，索引文件僅保存記錄所在頁的指針（物理位置），經過這些指針來讀取頁，進而讀取被索引的行。

樹中的葉子節點保存的是對應行的物理位置。經過該值，==存儲引擎能順利地進行回表查詢，獲得一行完整記錄==。

同時，每一個葉子也保存了指向下一個葉子的指針，從而方便葉子節點的範圍遍歷。

• 輔助索引

在MyISAM中，主鍵索引和輔助索引在結構上沒有任何區別，==只是主鍵索引要求key是惟一的，而輔助索引的key能夠重複==。

1）Innodb存儲引擎

Innodb的主鍵索引和輔助索引以前提到過，再回顧一次。

• 主鍵索引

InnoDB主鍵索引中既存儲了主健值，又存儲了行數據。

• 輔助索引

對於輔助索引，InnoDB採用的方式是在葉子節點中保存主鍵值，經過這個主鍵值來回表查詢到一條完整記錄，所以按輔助索引檢索其實進行了二次查詢，效率是沒有主鍵索引高的。

4、MySQL索引失效

在上一節中瞭解了索引的多種數據結構，以及B樹和B+樹的對比等，你們應該對索引的底層實現有了初步的瞭解。這一節從應用層的角度出發，看一下如何建索引更能知足咱們的需求，以及MySQL索引何時會失效的問題。

先來思考一個小問題。

問題：當查詢條件爲2個及2個以上時，是建立多個單列索引仍是建立一個聯合索引好呢？它們之間的區別是什麼？哪一個效率高呢？

先來創建一些單列索引進行測試：

這裏創建了一張表，裏面創建了三個單列索引userId,mobile,billMonth。

而後進行多列查詢。

explain select * from `t_mobilesms_11` where userid = '1' and mobile = '13504679876' and billMonth = '1998-03'

咱們發現查詢時只用到了userid這一個單列索引，這是爲何呢？由於這取決於MySQL優化器的優化策略。

當多條件聯合查詢時，優化器會評估哪一個條件的索引效率高，它會選擇最佳的索引去使用。也就是說，此處三個索引列均可能被用到，只不過優化器判斷只須要使用userid這一個索引就能完成本次查詢，故最終explain展現的key爲userid。

4.1 總結

多個單列索引在多條件查詢時優化器會選擇最優索引策略，可能只用一個索引，也可能將多個索引都用上。

可是多個單列索引底層會創建多個B+索引樹，比較佔用空間，也會浪費搜索效率
因此多條件聯合查詢時最好建聯合索引。

那聯合索引就能夠三個條件都用到了嗎？會出現索引失效的問題嗎？

4.2 聯合索引失效問題

該部分參考並引用文章：

一張圖搞懂MySQL的索引失效

建立user表，而後創建 name, age, pos, phone 四個字段的聯合索引
全值匹配（索引最佳）。

索引生效，這是最佳的查詢。

那麼時候會失效呢？

1）違反最左匹配原則

最左匹配原則：最左優先，以最左邊的爲起點任何連續的索引都能匹配上，如不連續，則匹配不上。

如：創建索引爲(a,b)的聯合索引，那麼只查 where b = 2 則不生效。換句話說：若是創建的索引是(a,b,c)，也只有(a),(a,b),(a,b,c)三種查詢能夠生效。

這裏跳過了最左的name字段進行查詢，發現索引失效了。

遇到範圍查詢（>、<、between、like）就會中止匹配。

好比：a= 1 and b = 2 and c>3 and d =4 若是創建(a,b,c,d)順序的索引，d是用不到索引的，由於c字段是一個範圍查詢，它以後的字段會中止匹配。

2）在索引列上作任何操做

如計算、函數、（手動或自動）類型轉換等操做，會致使索引失效而進行全表掃描。

explain select * from user where left(name,3) = 'zhangsan' and age =20

這裏對name字段進行了left函數操做，致使索引失效。

3）使用不等於（!= 、<>）

explain select * from user where age != 20;

explain select * from user where age <> 20;

4）like中以通配符開頭('%abc')

索引失效

explain select * from user where name like ‘%zhangsan’;

索引生效

explain select * from user where name like ‘zhangsan%’;

5）字符串不加單引號索引失效

explain select * from user where name = 2000;

6）or鏈接索引失效

explain select * from user where name = ‘2000’ or age = 20 or pos =‘cxy’;

7）order by

正常（索引參與了排序），沒有違反最左匹配原則。

explain select * from user where name = 'zhangsan' and age = 20 order by age,pos;

違反最左前綴法則，致使額外的文件排序（會下降性能）。

explain select name,age from user where name = 'zhangsan' order by pos;

8）group by

正常（索引參與了排序）。

explain select name,age from user where name = 'zhangsan' group by age;

違反最左前綴法則，致使產生臨時表（會下降性能）。

explain select name,age from user where name = 'zhangsan' group by pos,age;

5、總結

• 瞭解一條查詢語句是如何執行的，發現創建索引是一種能夠高效查找的數據結構。
• 瞭解了索引的各類分類狀況，彙集索引和非彙集索引的區別，如何建立各類索引。
• 經過需求一步步分析出爲何MySQL要選b+tree做爲索引的數據結構，對比了btree和b+tree的區別、 MyISAM和innodb中索引的區別。
• 瞭解了索引會失效的多種狀況，比較重要的最左匹配原則，相應地咱們能夠在建索引的時候作一些優化。

但願你們可以多去使用索引進行SQL優化，有問題歡迎指出。

來源：宜信技術學院

做者：楊亨