小編上文提及了幾種數據結構都不能很好的成功擔任Mysql索引結構，那麼誰又是Mysql那個心儀已久的白馬王子呢？且看B-樹和B+樹決戰紫晶之巔。
紅黑樹因為本身的樹高問題 , I/O多長效率不高，那麼是否有一種可以再樹每個節點存儲多個元素，就可以解決問題呢，對他就是B-樹。
1、B_樹數據結構
紅黑樹結構如圖：那麼每個節點存最大三個，第四產生轉換
當每個大節點超過節點容量時發生轉換。最終結果圖如下
相比較紅黑樹他的高度只有2，查詢速度更快。B-樹因此具有以下幾個特點：
1）、葉節點具有相同的深度，葉節點的指針為空
2）、所有索引元素不重複
3）、節點中的數據索引從左到右遞增排列
看完數據結構，我們看B樹做索引的結構又如何呢，mysql默認索引節點為16KB，當然可以修改大小。
B_樹索引算法的結構如下
可以看到每個數字代表一個索引（15,16指針等），後面空格代表葉子節點指針，那麼可以看到每個元素包含索引和元素代表的data數據（data可能是指針地址，也可能是數據），那麼按照1KB一行數據算一個節點就只能存不到16個元素。這樣的話數據的量級別又大打折扣。那麼有沒有更優秀的數據結構呢？
2、B+樹 （成功被寵幸的那一位）
B+樹 一個B_的變種，成功解決樹高，和訪問的結構。
B+樹數據結構中每個節點只存索引和下一個節點指針，最後子節點存數據加 索引：
下面以主鍵做例子：比如主鍵使用bigint數據類型是8b，指針佔6b,大小就是14b, 那麼16kb所有存滿一個節點就是16*1024/14= 1170,也就是1170個索引加1170個下一節點指針。以圖三層來算，三層高的樹將存儲：1170*1170*16 達到了兩千萬級別的數據量。那麼為什麼是16呢？因為我們每個data+索引假設為比較大數據的1KB來算的，要是更小的話數據級別將更大。（為何有15,20重複出現，應為右邊索引大於等於左邊）
同時B+樹在最後一層每個節點之間加入指針，做出了雙向的指針。為何這麼設計呢？那就是為了解決前面hash表中的不支持的範圍查找。
索引的類型
比如我用了>20時自己的節點處理完之後，沒有指針的話就又的從根節點去查找，指針可以根據節點的右邊大於等於左邊，同時頭尾都指針連接， <20也直接使用。
最終B+樹不出出誰與爭鋒。且看下次他如何笑傲MyISAM索引和InnoDB索引。也看看 為什麼InnoDB表必須有主鍵，並且推薦使用整型的自增主鍵？為什麼非主鍵索引結構葉子節點存儲的是主鍵值？(一致性和節省存儲空間)。
mysql可以每個表都設置不同的存儲引擎：大概分類
一、InnoDB
這是MySQL 5.5或更高版本的默認存儲引擎。它提供了事務安全(ACID兼容)表，支持外鍵引用完整性約束。它支持提交、回滾和緊急恢復功能來保護數據。它還支持行級鎖定。當在多用戶環境中使用時，它的「一致非鎖定讀取」提高了性能。它將數據存儲在集群索引中，從而減少了基於主鍵的查詢的I/O。
二、MyISAM
該存儲引擎管理非事務性表，提供高速存儲和檢索，支持全文搜索。
三、MEMORY
提供內存中的表，以前稱為堆。它在RAM中處理所有數據，以便比在磁碟上存儲數據更快地訪問。用於快速查找引用和其他相同的數據。
四、MERGE
將多個類似的MyISAM表分組為一個表，可以處理非事務性表，默認情況下包括這些表。
五、EXAMPLE
你可以使用此引擎創建表，但不能存儲或獲取數據。這樣做的目的是教開發人員如何編寫新的存儲引擎。
六、ARCHIVE
用於存儲大量數據，不支持索引。
七、CSV
在文本文件中以逗號分隔值格式存儲數據。
八、BLACKHOLE
受要存儲的數據，但始終返回空。
九、FEDERATED
將數據存儲在遠程資料庫中。