1，索引誰實現的：
索引是搜索引擎去實現的，在建立表的時候都會指定，搜索引擎是一種插拔式的，根據自己的選擇去決定使用哪一個。
2，索引的定義：
索引是為了加速對表中數據行的檢索而創建的一種分散存儲的（不連續的）數據結構，硬盤級的。
索引意義：索引能極大的減少存儲引擎需要掃描的數據量，索引可以把隨機IO變成順序IO。索引可以幫助我們在進行分組、排序等操作時，避免使用臨時表。正確的創建合適的索引是提升數據庫查詢性能的基礎。
3，為什么選擇B+Tree：
B+樹索引是B+樹在數據庫中的一種實現，是最常見也是數據庫中使用最為頻繁的一種索引。B+樹中的B代表平衡（balance），而不是二叉（binary），因為B+樹是從最早的平衡二叉樹演化而來的。先了解二叉查找樹、平衡二叉樹（AVLTree）和平衡多路查找樹（B-Tree），B+樹即由這些樹逐步優化而來。
二叉查找樹：
二叉樹具有以下性質：左子樹的鍵值小於根的鍵值，右子樹的鍵值大於根的鍵值。 如下圖所示就是一棵二叉查找樹，:
對該二叉樹的節點進行查找發現深度為1的節點的查找次數為1，深度為2的查找次數為2，深度為n的節點的查找次數為n，因此其平均查找次數為 (1+2+2+3+3+3) / 6 = 2.3次。二叉查找樹可以任意地構造，同樣是2,3,5,6,7,8這六個數字，也可以按照下圖的方式來構造：
但是這棵二叉樹的查詢效率就低了。因此若想二叉樹的查詢效率盡可能高，需要這棵二叉樹是平衡的，從而引出新的定義——平衡二叉樹，或稱AVL樹。
平衡二叉樹（AVL Tree）：
平衡二叉樹（AVL樹）在符合二叉查找樹的條件下，還滿足任何節點的兩個子樹的高度最大差為1。下面的兩張圖片，左邊是AVL樹，它的任何節點的兩個子樹的高度差<=1；右邊的不是AVL樹，其根節點的左子樹高度為3，而右子樹高度為1；
如果在AVL樹中進行插入或刪除節點，可能導致AVL樹失去平衡，這種失去平衡的二叉樹可以概括為四種姿態：LL（左左）、RR（右右）、LR（左右）、RL（右左）。它們的示意圖如下：
這四種失去平衡的姿態都有各自的定義：
LL：LeftLeft，也稱“左左”。插入或刪除一個節點后，根節點的左孩子（Left Child）的左孩子（Left Child）還有非空節點，導致根節點的左子樹高度比右子樹高度高2，AVL樹失去平衡。
RR：RightRight，也稱“右右”。插入或刪除一個節點后，根節點的右孩子（Right Child）的右孩子（Right Child）還有非空節點，導致根節點的右子樹高度比左子樹高度高2，AVL樹失去平衡。
LR：LeftRight，也稱“左右”。插入或刪除一個節點后，根節點的左孩子（Left Child）的右孩子（Right Child）還有非空節點，導致根節點的左子樹高度比右子樹高度高2，AVL樹失去平衡。
RL：RightLeft，也稱“右左”。插入或刪除一個節點后，根節點的右孩子（Right Child）的左孩子（Left Child）還有非空節點，導致根節點的右子樹高度比左子樹高度高2，AVL樹失去平衡。
AVL樹失去平衡之后，可以通過旋轉使其恢復平衡。下面分別介紹四種失去平衡的情況下對應的旋轉方法。
LL的旋轉。LL失去平衡的情況下，可以通過一次旋轉讓AVL樹恢復平衡。步驟如下：
- 將根節點的左孩子作為新根節點。
- 將新根節點的右孩子作為原根節點的左孩子。
- 將原根節點作為新根節點的右孩子。
LL旋轉示意圖如下：
RR的旋轉：RR失去平衡的情況下，旋轉方法與LL旋轉對稱，步驟如下：
- 將根節點的右孩子作為新根節點。
- 將新根節點的左孩子作為原根節點的右孩子。
- 將原根節點作為新根節點的左孩子。
LR的旋轉：LR失去平衡的情況下，需要進行兩次旋轉，步驟如下：
- 圍繞根節點的左孩子進行RR旋轉。
- 圍繞根節點進行LL旋轉。
RL的旋轉：RL失去平衡的情況下也需要進行兩次旋轉，旋轉方法與LR旋轉對稱，步驟如下：
- 圍繞根節點的右孩子進行LL旋轉。
- 圍繞根節點進行RR旋轉。
那么使用平衡二叉樹作為索引數據結構的話會是怎么樣的呢？先看一下下圖：
可以把每個節點看成一個磁盤塊，每個磁盤塊存儲的信息如右邊這個結構圖所示。
關鍵字：即我們建立索引的關鍵字段的對應值。
數據區：即關鍵字對應的數據存儲磁盤位置，通過關鍵字所對應的磁盤位置進行IO讀寫操作獲取數據。
節點引用：即指向子節點的磁盤位置。
如果要查找ID為8的數據，那么先會獲取根節點10加載到內存中，比較數據大小，發現比10小，那么查找左節點5，發現比5大，查找5的右節點，發現命中，然后根據數據區地址去進行IO讀寫操作。但是B-Tree有如下缺點：
它太深了，數據處的（高）深度決定着他的IO操作次數，IO操作耗時大。它太小了，每一個磁盤塊（節點/頁）保存的數據量太小了。沒有很好的利用操作磁盤IO的數據交換特性，一次IO操作以頁為單位 ，4KB，那么加載一次絕對不會達到4KB.也沒有利用好磁盤IO的預讀能力（空間局部性原理），從而帶來頻繁的IO操作
平衡多路查找樹（B-Tree）：
B-Tree是為磁盤等外存儲設備設計的一種平衡查找樹。因此在講B-Tree之前先了解下磁盤的相關知識。
系統從磁盤讀取數據到內存時是以磁盤塊（block）為基本單位的，位於同一個磁盤塊中的數據會被一次性讀取出來，而不是需要什么取什么。InnoDB存儲引擎中有頁（Page）的概念，頁是其磁盤管理的最小單位。InnoDB存儲引
擎中默認每個頁的大小為16KB，可通過參數innodb_page_size將頁的大小設置為4K、8K、16K，在MySQL中可通過如下命令查看頁的大小：mysql> show variables like 'innodb_page_size';
而系統一個磁盤塊的存儲空間往往沒有這么大，因此InnoDB每次申請磁盤空間時都會是若干地址連續磁盤塊來達到頁的大小16KB。InnoDB在把磁盤數據讀入到磁盤時會以頁為基本單位，在查詢數據時如果一個頁中的每條數據都
能有助於定位數據記錄的位置，這將會減少磁盤I/O次數，提高查詢效率。B-Tree結構的數據可以讓系統高效的找到數據所在的磁盤塊。為了描述B-Tree，首先定義一條記錄為一個二元組[key, data] ，key為記錄的鍵值，對應表中的主鍵
值，data為一行記錄中除主鍵外的數據。對於不同的記錄，key值互不相同。一棵m階的B-Tree有如下特性：
1. 每個節點最多有m個孩子。
2. 除了根節點和葉子節點外，其它每個節點至少有Ceil(m/2)個孩子。
3. 若根節點不是葉子節點，則至少有2個孩子
4. 所有葉子節點都在同一層，且不包含其它關鍵字信息
5. 每個非終端節點包含n個關鍵字信息（P0,P1,…Pn, k1,…kn）
6. 關鍵字的個數n滿足：ceil(m/2)-1 <= n <= m-1
7. ki(i=1,…n)為關鍵字，且關鍵字升序排序。
8. Pi(i=1,…n)為指向子樹根節點的指針。P(i-1)指向的子樹的所有節點關鍵字均小於ki，但都大於k(i-1)
B-Tree中的每個節點根據實際情況可以包含大量的關鍵字信息和分支，如下圖所示為一個3階的B-Tree:
每個節點占用一個盤塊的磁盤空間，一個節點上有兩個升序排序的關鍵字和三個指向子樹根節點的指針，指針存儲的是子節點所在磁盤塊的地址。兩個關鍵詞划分成的三個范圍域對應三個指針指向的子樹的數據的范圍域。以根節點為例，關鍵字為17和35，P1指針指向的子樹的數據范圍為小於17，P2指針指向的子樹的數據范圍為17~35，P3指針指向的子樹的數據范圍為大於35。模擬查找關鍵字29的過程：
- 根據根節點找到磁盤塊1，讀入內存。【磁盤I/O操作第1次】
- 比較關鍵字29在區間（17,35），找到磁盤塊1的指針P2。
- 根據P2指針找到磁盤塊3，讀入內存。【磁盤I/O操作第2次】
- 比較關鍵字29在區間（26,30），找到磁盤塊3的指針P2。
- 根據P2指針找到磁盤塊8，讀入內存。【磁盤I/O操作第3次】
- 在磁盤塊8中的關鍵字列表中找到關鍵字29。
分析上面過程，發現需要3次磁盤I/O操作，和3次內存查找操作。由於內存中的關鍵字是一個有序表結構，可以利用二分法查找提高效率。而3次磁盤I/O操作是影響整個B-Tree查找效率的決定因素。B-Tree相對於AVLTree縮減了節點個數，使每次磁盤I/O取到內存的數據都發揮了作用，從而提高了查詢效率。
我們可以來算一筆賬，以InnoDB存儲引擎中默認每個頁的大小為16KB來計算，假設以int型的ID作為索引關鍵字，那么 一個int占用4byte，由上圖可以知道還有其他的除主鍵以外的數據，姑且頁當成4byte，那么這里就是8byte，那么16KB=16*1024byte，那么我們在這種場景下，可以定義這個B-Tree的階樹為 （16*1024）/8=2048.那么這個樹將會有2048-1路，也就是原來平衡二叉樹(兩路)的1024倍左右，從而大大提高了查找效率與降低IO讀寫次數。
B-Tree為了保證絕對平衡他有自己的機制，比如每個節點上的關鍵字個數=路數（階數-1），如下圖：
可以看到添加節點后違反了原有的規則，這個時候會進行分裂。結果就會形成一根最新的樹，（如果分裂過程中23 333 這個節點頁不滿足了會繼續向上分裂）：
所以建立合適的索引是很重要的 ，不宜多，當加一條數據，整棵樹會進行重組。
B+Tree：
B+Tree是在B-Tree基礎上的一種優化，使其更適合實現外存儲索引結構，InnoDB存儲引擎就是用B+Tree實現其索引結構。
從 B-Tree 結構圖中可以看到每個節點中不僅包含數據的key值，還有data值。而每一個頁的存儲空間是有限的，如果data數據較大時將會導致每個節點（即一個頁）能存儲的key的數量很小，當存儲的數據量很大時同樣會導致B-Tree的深度較大，增大查詢時的磁盤I/O次數，進而影響查詢效率。在B+Tree中，所有數據記錄節點都是按照鍵值大小順序存放在同一層的葉子節點上，而非葉子節點上只存儲key值信息，這樣可以大大加大每個節點存儲的key值數量，降低B+Tree的高度。
B+Tree相對於B-Tree有幾點不同：
- B+節點關鍵字搜索采用閉合區間
- B+非葉節點不保存數據相關信息，只保存關鍵字和子節點的引用
- B+關鍵字對應的數據保存在葉子節點中
- B+葉子節點是順序排列的，並且相鄰節點具有順序引用的關系
將B-Tree優化，由於B+Tree的非葉子節點只存儲鍵值信息，假設每個磁盤塊能存儲4個鍵值及指針信息，則變成B+Tree后其結構如下圖所示：
通常在B+Tree上有兩個頭指針，一個指向根節點，另一個指向關鍵字最小的葉子節點，而且所有葉子節點（即數據節點）之間是一種鏈式環結構。因此可以對B+Tree進行兩種查找運算：一種是對於主鍵的范圍查找和分頁查找，另一種是從根節點開始，進行隨機查找。可能上面例子中只有22條數據記錄，看不出B+Tree的優點，下面做一個推算：InnoDB存儲引擎中頁的大小為16KB，一般表的主鍵類型為INT（占用4個字節）或BIGINT（占用8個字節），指針類型也一般為4或8個字節，也就是說一個頁（B+Tree中的一個節點）中大概存儲16KB/(8B+8B)=1K個鍵值（因為是估值，為方便計算，這里的K取值為〖10〗^3）。也就是說一個深度為3的B+Tree索引可以維護10^3 * 10^3 * 10^3 = 10億 條記錄。
實際情況中每個節點可能不能填充滿，因此在數據庫中，B+Tree的高度一般都在2~4層。mysql 的InnoDB存儲引擎在設計時是將根節點常駐內存的，也就是說查找某一鍵值的行記錄時最多只需要1~3次磁盤I/O操作。數據庫中的B+Tree索引可以分為聚集索引（clustered index）和輔助索引（secondary index）。上面的B+Tree示例圖在數據庫中的實現即為聚集索引，聚集索引的B+Tree中的葉子節點存放的是整張表的行記錄數據。輔助索引與聚集索引的區別在於輔助索引的葉子節點並不包含行記錄的全部數據，而是存儲相應行數據的聚集索引鍵，即主鍵。當通過輔助索引來查詢數據時，InnoDB存儲引擎會遍歷輔助索引找到主鍵，然后再通過主鍵在聚集索引中找到完整的行記錄數據。
B+Tree在MYSQL中采用的是左閉合區間，MYSQL推崇使用ID作為索引，由於ID是自增的數字類型，只會增大，所以采用向右拓展的一個方式，從根節點進行比對，由於枝節點不保存數據，無所謂命不命中，都要繼續走到葉子節點才能加載數據。
B+樹是B-樹的變種（PLUS版）多路絕對平衡查找樹，他擁有B-樹的優勢。
B+樹掃庫、表能力更強。
B+樹的磁盤讀寫能力更強。
B+樹的排序能力更強。
B+樹的查詢效率更加穩定（仁者見仁、智者見智）。
4，B+Tree在兩大引擎中如何體現：
索引的實現是由搜索引擎來實現的，那么在 MYSQL中比較主流的兩大引擎是：Myisam 跟 innoDB，存儲引擎是建立在表上面的，在建立表的時候可以指定所需要的搜索引擎。例如下列的創建語句中就指定了搜索引擎為：ENGINE=InnoDB，不指定就使用默認的InnoDB
CREATE TABLE `user` ( `id` int(11) NOT NULL, `name` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
B+Tree 在 Myisam 中的體現：
在創建好表結構並且指定搜索引擎為 Myisam之后，會在數據目錄生成3個文件，分別是table_name.frm(表結構文件)，table_name.MYD（數據保存文件）,table_name.MYI（索引保存文件）。
例如上訴 teacher表，兩個文件分別保存了數據及索引，由於B+Tree中只有葉子節點保存數據區，在Myisam中，數據區中保存的是數據的引用地址，就比如說ID為101的數據信息所保存到物理磁盤地址為 0x123456,在索引中的節點數據去中所保存的就是這個磁盤地址指針。當掃描到這個指針位置，就可以通過這個磁盤指針講數據加載出來。
在Myisam中B+Tree的實現中比如現在不用ID作為索引了，要用name，那么他的一個展現形式有事怎么樣的呢？其實他與ID作為索引是一樣的，也是保存他指定的磁盤位置指針，他們是平級的。如下圖：
B+Tree 在 InnoDB 中的體現：
在創建好表結構並且指定搜索引擎為 InnoDB之后，會在數據目錄生成3個文件，分別是table_name.frm(表結構文件)，table_name.idb（數據與索引保存文件）。
在 InnoDB中，因為設計之初就是認為主鍵是非常重要的。是以主鍵為索引來組織數據的存儲，當我們沒有顯示的建立主鍵索引的時候，搜索引擎會隱式的為我們建立一個主鍵索引以組織數據存儲。數據庫表行中數據的物理順序與鍵值的邏輯（索引）順序相同，InnoDB就是以聚集索引來組織數據的存儲的，在葉子節點上，保存了數據的所有信息。如果這個時候建立了name字段的索引：
會產生一個輔助索引，即name字段的索引，而此刻葉子節點上所保存的數據為 聚集索引（ID索引）的關鍵字的值，基於輔助索引找到ID索引的值，再通過ID索引區獲取最終的數據。這個做法的好處是在於產生數據遷移的時候只要ID沒發生變法，那么輔助索引不需要重新生成，不這么做的話，如果存儲的是磁盤地址的話，在數據遷移后所有輔助索引都需要重新生成。
5，索引知識：
找出離散性最好的列：
越大離散型越好 count(distinct col):count(col) 理解為差異性。結論：離散性越高選擇性就越好，比如有一個性別的字段的索引，假設男為1，女為0：就會生成一下一個索引樹：
這個時候要搜索女的數據，那么在根節點觸發，可以由兩條路可以走，從中間走下去的話發現可以選擇的線路太多了，這樣會導致搜索引擎懵逼，優化器覺得既然要搜索這么多數據，還不如全表掃描呢，這就導致離散型降低。不利於性能。
最左匹配原則：
對索引中關鍵字進行計算（對比），一定是從左往右依次進行，且不可跳過，在創建數據庫的時候需要選擇字符集及排序規則，這都是有用的 ，比如一棵B-tree中的根節點為一個字符串 abc ，那么我現在要搜索一個為 adc的索引關鍵字的數據，根節點abc的ASCII 碼為 97 98 99，而 adc的為 97 100 99，那么和3個數字會逐一比對，且100>98，接下去一定會走右子樹。
聯合索引：
單列索引：節點中關鍵字[name] 及索引的關鍵字的值為那么對應的值 ，比如 張三。
聯合索引：節點中關鍵字[name,phoneNum]比如張三，138888888。
聯合索引列選擇原則。
- 經常用的列優先 【最左匹配原則】。
- 選擇性（離散度）高的列優先【離散度高原則】。
- 寬度小的列優先【最少空間原則】。
示例：經排查發現最常用的sql語句：Select * from users where name = ? ;Select * from users where name = ? and phoneNum = ?;
機靈的李二狗的解決方案：create index idx_name on users(name);--（冗余索引 最左原則，下面這個聯合索引適用於以上2個sql語句）；create index idx_name_phoneNum on users(name,phoneNum);
所以在這種情況下只需要建立一個聯合索引即可，會根據最左匹配原則去匹配的。
覆蓋索引：
如果查詢列可通過索引節點中的關鍵字直接返回，則該索引稱之為覆蓋索引。覆蓋索引可減少數據庫IO，將隨機IO變為順序IO，可提高查詢性能。比說所建立了一個聯合索引 reate index idx_name_phoneNum on users(name,phoneNum);而此刻有sql select name phoneNum from 。。。。這個就是覆蓋索引。
6，總結及驗證：
索引列的數據長度能少則少。索引一定不是越多越好，越全越好，一定是建合適的。查詢條件上有計算函數無法命中索引。
匹配列前綴：like 9999%（最原則上按照左匹配上來說是可以的，但是不一定能用到索引，當離散性太差的時候就不行），like %9999%（不行）、like %9999（不行）用不到索引；
Where 條件中 not in 和 <>操作無法使用索引；匹配范圍值，order by 也可用到索引；多用指定列查詢，只返回自己想到的數據列，少用select *；
聯合索引中如果不是按照索引最左列開始查找，無法使用索引；
聯合索引中精確匹配最左前列並范圍匹配另外一列可以用到索引；比如聯合索引【name，phoneNum】，當SQL為：select .....where name='1' and phoneNum>xxxxxxx.
聯合索引中如果查詢中有某個列的范圍（大於小於）查詢，則其右邊的所有列都無法使用索引；
最后送上一首網友提供的打油詩：
全值匹配我最愛，最左前綴要遵守；
帶頭大哥不能死，中間兄弟不能斷；
索引列上少計算，范圍之后全失效；
Like百分寫最右，覆蓋索引不寫星；
不等空值還有or，索引失效要少用；
VAR引號不可丟，SQL高級也不難！