數據庫，從B+樹講到索引優化，聽不明白你找我

1、什麼是索引

在進行索引以前，咱們先提早複習一下數據庫的結構

數據庫索引，是數據庫管理系統中一個排序的數據結構，以協助快速查詢、更新數據庫表中數據。就像咱們之前用的新華字典的目錄同樣，能幫助咱們快速查詢到某一個字。

具體的來看一下

2、索引的分類

分類角度索引名稱數據結構B+樹，Hash索引，R-Tree等存儲層面聚簇索引，非聚簇索引邏輯層面主鍵索引，普通索引，複合索引，惟一索引，空間索引等

這樣說有點不明白？圖解奉上

還不明白，不要緊，這麼看圖確實有點抽象，那咱們就來看一下實例

3、索引實例分析(以InnoDB爲例)

3.1 InnoDB下索引的結構

InnoDB下，表都是根據主鍵順序以索引的形式存放的，這種數據存儲方式也被稱爲聚簇索引，「聚簇」就是表示數據行和相鄰的鍵值緊湊的存儲在一塊兒，也就是數據行其實是存儲在索引的葉子頁中。咱們建立一張表來實際說明下InnoDB下的索引結構，建表語句以下：

create table person(id int primary key, age int not nullindex (age)engine=InnoDB;

而後咱們插入五條數據分別爲(1,15),(2,17),(6,20),(10,18),(19,21)，索引的樹結構以下：

上圖中展現了兩部份內容，第一個圖爲聚簇索引（主鍵索引）的內容，能夠看到，數據按照Id的大小排序，對應的索引會包含該索引的整行數據。

第二個圖展現了用age作索引的索引結構圖，也就是非聚簇索引（非主鍵索引），能夠看到索引以年齡排序，可是和主鍵索引不一樣的是，年齡索引對應的倒是Id，因此咱們能夠知道非主鍵索引記錄的內容就是主鍵索引的值。

這裏可能有同窗會有疑問，若是我建表的時候沒有指定主鍵的話，索引結構又是如何的呢？其實在InnoDB中，若是沒有定義主鍵，那麼他會選擇一個惟一的非空索引代替。若是沒有這樣的索引，那麼他會隱式的定義一個主鍵來做爲聚簇索引。因此不管你是否設置主鍵，InnoDB仍是會幫你知足以上圖的形式來索引數據。接下來咱們分析下索引查詢的流程。

3.2 索引查詢分析

假設咱們執行一條查詢語句 select * from person where ID = 6 ,由於直接使用的是主鍵ID查詢，因此就會用主鍵索引，因爲主鍵索引直接關聯了整行全部數據，因此，引擎只要執行一次就能查詢出結果。

若是執行的sql語句是非主鍵索引

select * from person where age = 18

上述語句會走age的普通索引，索引先根據age搜索等於18的索引記錄，找到ID=10的記錄，而後再到主鍵索引搜索一次，而後拿出須要查詢的數據。

從普通索引查出主鍵索引，而後查詢出數據的過程叫作回表。因爲回表須要多執行一次查詢，這也是爲何主鍵索引要比普通索引要快的緣由，因此，咱們要儘可能使用主鍵查詢。

3.3 覆蓋索引

咱們一般建立索引的依據都是根據查詢的where條件，可是這只是咱們一般的作法，咱們根據上面的分析能夠知道，若是要想查詢效率高，第一，使用主鍵索引，第二，避免回表，也就是儘量的在索引中就能獲取想要的數據。若是一個索引包含了須要查詢的字段，那麼咱們就叫作「覆蓋索引」。

那麼如何創建一個覆蓋索引呢？答案是經過聯合索引來實現，經過聯合索引的字段來覆蓋要查詢的字段，從而達到索引覆蓋的效果。

咱們把上面的建表語句改造下，來分析下如何實現覆蓋索引。

CREATE TABLE `person` (  `id` int(11) NOT NULL,  `age` int(11) DEFAULT NULL,  `name` varchar(20) DEFAULT NULL,  `sex` varchar(1) DEFAULT NULL,  PRIMARY KEY (`id`),  KEY `name_age` (`name`,`age`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;

上面我建立了一個name和age的聯合索引，索引結構圖表示以下：

咱們根據圖能夠知道，聯合索引是和建立索引字段順序有關的，上面這個例子就是先以name排序，而後name相同再以age爲標準排序。那麼咱們建表後該如何達到覆蓋索引的效果呢？相信有些同窗已經知道了怎麼寫sql能夠達到覆蓋索引效果，sql以下：

select name,age from person where name = "Barry"

由於咱們須要查詢的字段name和age，都在索引中能夠直接查詢到了，因此不須要查找到主鍵ID，而後再回表了。

看到這裏，確定有同窗會說，既然這樣的話，我把全部須要查詢的字段組合都建上聯合索引不就好了嗎？答案是：不行。由於索引也是須要消耗空間的，並且維護索引也是須要成本的，這一點我會在後面的優缺點中提到。那麼有沒有別的方式能夠儘量的實現不回表的效果呢？這裏咱們就要引入MySql的最左前綴原則了。

什麼叫最左前綴原則呢？就是在索引的匹配中，能夠以索引的最左N個字段,也能夠是字符串索引的最左N個字符。好比在上圖中，要查詢以A開頭的名字，查詢語句就是

select name from person where name like 'A%'

這個時候就能夠知足最左前綴規則來使用索引查詢了，這裏就會依賴索引查詢到第一個首字母是A的名字，而後向後遍歷，直到不知足條件爲止。

那麼最左N個字段是什麼意思呢？意思就是索引（name,age),能夠直接利用 name來當作單獨索引使用，能夠只使用聯合索引的部分字段，可是必須是順序一致，好比索引（a,b,c)，若是要想使用最左前綴規則，可使用索引a,ab。

咱們也能夠利用該規則來少維護一個或多個索引，好比咱們須要 a,ab,abc的查詢，那就只須要(a,b,c)聯合索引就知足要求了。

3.4 索引下推

在MySql 5.6版本中引入了一個新特性，叫作「索引條件推送（index condition pushdown)」，這也稱爲索引下推。那麼索引下推是這個什麼東東呢？其實從「索引條件推送」這個名字就能夠代表，這個特性是能夠在索引中的字段進行條件判斷，而後過濾不知足條件的記錄，減小回表的次數。

好比以上圖中的數據爲準，sql以下：

select * from person where name like 'A%' and age =19;

那麼若是沒有索引下推的狀況下，首先會根據索引查詢出名字以A開頭的全部記錄，而後查詢出ID，而後回表去查詢對應的ID記錄，最後再判斷age=19，返回知足條件的語句。由於知足A開頭的記錄有2條，因此這種狀況下，會回表2次。

在索引下推狀況下，InnoDB會在索引內部直接判斷age=19是否知足條件，過濾掉不知足條件的記錄，因此只返回了一條，也就是隻須要回表一次。從而提升了性能。

3.5 索引的優勢與缺點

說了這麼多關於索引的內容，咱們來談談索引的優缺點。

優勢：

• 減小服務器須要掃描的數據量
• 索引能夠幫助服務器避免排序和臨時表
• 索引能夠將隨機IO變爲順序IO

缺點

• 索引會佔用額外的存儲空間
• 索引的維護須要必定的成本，插入數據後須要保證原來的索引有序，因此也會影響必定的數據庫性能。
• • *

因此在優化方面，索引優化算是數據庫優化中很重要的一個環節，這裏由於篇幅緣由我就不一一詳解了，相關的內容我已經完整整理成思惟導圖，每個方面整理的都很詳細

須要這份優化思惟導圖以及上面的知識圖的老鐵，同步的還有相關的視頻講解以及學習文檔，還不快點行動
關注公衆號：Java架構師聯盟，每日更新技術好文

部分資料已經上傳到個人git倉庫中：有須要的能夠下載

https://gitee.com/biwangsheng/mxq