原因：相對於B樹，

（1）B+樹空間利用率更高，可減少I/O次數，

一般來說，索引本身也很大，不可能全部儲存在記憶體中，因此索引往往以索引檔案的形式儲存的磁碟上。這樣的話，索引查詢過程中就要產生磁碟I/O消耗。而因為B+樹的內部節點只是作為索引使用，而不像B-樹那樣每個節點都需要儲存硬碟指標。

也就是說：B+樹中每個非葉節點沒有指向某個關鍵字具體資訊的指標，所以每一個節點可以存放更多的關鍵字數量，即一次性讀入記憶體所需要查詢的關鍵字也就越多，減少了I/O操作。

 e.g.假設磁碟中的一個盤塊容納16bytes，而一個關鍵字2bytes，一個關鍵字具體資訊指標2bytes。一棵9階B-tree(一個結點最多8個關鍵字)的內

（2）增刪檔案（節點）時，效率更高，

     因為B+樹的葉子節點包含所有關鍵字，並以有序的連結串列結構儲存，這樣可很好提高增刪效率。

B+樹在資料庫中的應用

1. 索引在資料庫中的作用 

        在資料庫系統的使用過程當中，資料的查詢是使用最頻繁的一種資料操作。

        最基本的查詢演算法當然是順序查詢（linear search），遍歷表然後逐行匹配行值是否等於待查詢的關鍵字，其時間複雜度為O（n）。但時間複雜度為O（n）的演算法規模小的表，負載輕的資料庫，也能有好的效能。  但是資料增大的時候，時間複雜度為O（n）的演算法顯然是糟糕的，效能就很快下降了。

       好在電腦科學的發展提供了很多更優秀的查詢演算法，例如二分查詢（binary search）、二叉樹查詢（binary tree search）等。如果稍微分析一下會發現，每種查詢演算法都只能應用於特定的資料結構之上，例如二分查詢要求被檢索資料有序，而二叉樹查詢只能應用於二叉查詢樹上

       索引是對資料庫表 中一個或多個列的值進行排序的結構。與在表 中搜索所有的行相比，索引用指標 指向儲存在表中指定列的資料值，然後根據指定的次序排列這些指標，有助於更快地獲取資訊。通常情 況下 ，只有當經常查詢索引列中的資料時 ，才需要在表上建立索引。索引將佔用磁碟空間，並且影響數 據更新的速度。但是在多數情況下 ，索引所帶來的資料檢索速度優勢大大超過它的不足之處。

2. B+樹在資料庫索引中的應用

目前大部分資料庫系統及檔案系統都採用B-Tree或其變種B+Tree作為索引結構

1）在資料庫索引的應用

在資料庫索引的應用中，B+樹按照下列方式進行組織   ：

①  葉結點的組織方式 。B+樹的查詢鍵 是資料檔案的主鍵 ，且索引是稠密的。也就是說 ，葉結點 中為資料檔案的第一個記錄設有一個鍵、指標對，該資料檔案可以按主鍵排序，也可以不按主鍵排序 ；資料檔案按主鍵排序，且 B +樹是稀疏索引 ，  在葉結點中為資料檔案的每一個塊設有一個鍵、指標對 ；資料檔案不按鍵屬性排序 ，且該屬性是 B +樹 的查詢鍵 ， 葉結點中為資料檔案裡出現的每個屬性K設有一個鍵 、 指標對 ， 其中指標執行排序鍵值為 K的 記錄中的第一個。

② 非葉結點 的組織方式。B+樹 中的非葉結點形成 了葉結點上的一個多級稀疏索引。  每個非葉結點中至少有ceil( m/2 ) 個指標 ， 至多有 m 個指標 。  

2）B+樹索引的插入和刪除

①在向資料庫中插入新的資料時，同時也需要向資料庫索引中插入相應的索引鍵值 ，則需要向 B+樹 中插入新的鍵值。即上面我們提到的B-樹插入演算法。

②當從資料庫中刪除資料時，同時也需要從資料庫索引中刪除相應的索引鍵值 ，則需要從 B+樹 中刪 除該鍵值 。即B-樹刪除演算法

為什麼使用B-Tree（B+Tree）

     二叉查詢樹進化品種的紅黑樹等資料結構也可以用來實現索引，但是檔案系統及資料庫系統普遍採用B-/+Tree作為索引結構。

　一般來說，索引本身也很大，不可能全部儲存在記憶體中，因此索引往往以索引檔案的形式儲存的磁碟上。這樣的話，索引查詢過程中就要產生磁碟I/O消耗，相對於記憶體存取，I/O存取的消耗要高几個數量級，所以評價一個數據結構作為索引的優劣最重要的指標就是在查詢過程中磁碟I/O操作次數的漸進複雜度。換句話說，索引的結構組織要儘量減少查詢過程中磁碟I/O的存取次數。為什麼使用B-/+Tree，還跟磁碟存取原理有關。

       區域性性原理與磁碟預讀

　　由於儲存介質的特性，磁碟本身存取就比主存慢很多，再加上機械運動耗費，磁碟的存取速度往往是主存的幾百分分之一，因此為了提高效率，要儘量減少磁碟I/O。為了達到這個目的，磁碟往往不是嚴格按需讀取，而是每次都會預讀，即使只需要一個位元組，磁碟也會從這個位置開始，順序向後讀取一定長度的資料放入記憶體。這樣做的理論依據是電腦科學中著名的區域性性原理：

　　當一個數據被用到時，其附近的資料也通常會馬上被使用。

　　程式執行期間所需要的資料通常比較集中。

　　由於磁碟順序讀取的效率很高（不需要尋道時間，只需很少的旋轉時間），因此對於具有區域性性的程式來說，預讀可以提高I/O效率。

　　預讀的長度一般為頁（page）的整倍數。頁是計算機管理儲存器的邏輯塊，硬體及作業系統往往將主存和磁碟儲存區分割為連續的大小相等的塊，每個儲存塊稱為一頁（在許多作業系統中，頁得大小通常為4k），主存和磁碟以頁為單位交換資料。當程式要讀取的資料不在主存中時，會觸發一個缺頁異常，此時系統會向磁碟發出讀盤訊號，磁碟會找到資料的起始位置並向後連續讀取一頁或幾頁載入記憶體中，然後異常返回，程式繼續執行。

      我們上面分析B-/+Tree檢索一次最多需要訪問節點：

     h =

      資料庫系統巧妙利用了磁碟預讀原理，將一個節點的大小設為等於一個頁，這樣每個節點只需要一次I/O就可以完全載入。為了達到這個目的，在實際實現B- Tree還需要使用如下技巧：

      每次新建節點時，直接申請一個頁的空間，這樣就保證一個節點物理上也儲存在一個頁裡，加之計算機儲存分配都是按頁對齊的，就實現了一個node只需一次I/O。

　　B-Tree中一次檢索最多需要h-1次I/O（根節點常駐記憶體），漸進複雜度為O（h）=O（logmN）。一般實際應用中，m是非常大的數字，通常超過100，因此h非常小（通常不超過3）。

　　綜上所述，用B-Tree作為索引結構效率是非常高的。

　　而紅黑樹這種結構，h明顯要深的多。由於邏輯上很近的節點（父子）物理上可能很遠，無法利用區域性性，所以紅黑樹的I/O漸進複雜度也為O（h），效率明顯比B-Tree差很多。

MySQL的B-Tree索引（技術上說B+Tree）

       在 MySQL 中，主要有四種類型的索引，分別為： B-Tree 索引， Hash 索引， Fulltext 索引和 R-Tree 索引。我們主要分析B-Tree 索引。

        B-Tree 索引是 mysql 資料庫中使用最為頻繁的索引型別，除了 Archive 儲存引擎之外的其他所有的儲存引擎都支援 B-Tree 索引。Archive 引擎直到 MySQL 5.1 才支援索引，而且只支援索引單個 AUTO_INCREMENT 列。

       不僅僅在 MySQL 中是如此，實際上在其他的很多資料庫管理系統中B-Tree 索引也同樣是作為最主要的索引型別，這主要是因為 B-Tree 索引的儲存結構在資料庫的資料檢索中有非常優異的表現。

     一般來說， MySQL 中的 B-Tree 索引的物理檔案大多都是以 Balance Tree 的結構來儲存的，也就是所有實際需要的資料都存放於 Tree 的 Leaf Node(葉子節點) ，而且到任何一個 Leaf Node 的最短路徑的長度都是完全相同的，所以我們大家都稱之為 B-Tree 索引。當然，可能各種資料庫（或 MySQL 的各種儲存引擎）在存放自己的 B-Tree 索引的時候會對儲存結構稍作改造。如 Innodb 儲存引擎的 B-Tree 索引實際使用的儲存結構實際上是B+Tree，也就是在 B-Tree 資料結構的基礎上做了很小的改造，在每一個Leaf Node 上面出了存放索引鍵的相關資訊之外，還儲存了指向與該 Leaf Node 相鄰的後一個 LeafNode 的指標資訊（增加了順序訪問指標），這主要是為了加快檢索多個相鄰 Leaf Node 的效率考慮。

下面主要討論MyISAM和InnoDB兩個儲存引擎的索引實現方式：

1. MyISAM索引實現：

1）主鍵索引：

MyISAM引擎使用B+Tree作為索引結構，葉節點的data域存放的是資料記錄的地址。下圖是MyISAM主鍵索引的原理圖：

                                                                           （圖myisam1）

這裡設表一共有三列，假設我們以Col1為主鍵，圖myisam1是一個MyISAM表的主索引（Primary key）示意。可以看出MyISAM的索引檔案僅僅儲存資料記錄的地址。

2）輔助索引（Secondary key）

在MyISAM中，主索引和輔助索引（Secondary key）在結構上沒有任何區別，只是主索引要求key是唯一的，而輔助索引的key可以重複。如果我們在Col2上建立一個輔助索引，則此索引的結構如下圖所示：
  

同樣也是一顆B+Tree，data域儲存資料記錄的地址。因此，MyISAM中索引檢索的演算法為首先按照B+Tree搜尋演算法搜尋索引，如果指定的Key存在，則取出其data域的值，然後以data域的值為地址，讀取相應資料記錄。

MyISAM的索引方式也叫做“非聚集”的，之所以這麼稱呼是為了與InnoDB的聚集索引區分。

2. InnoDB索引實現

然InnoDB也使用B+Tree作為索引結構，但具體實現方式卻與MyISAM截然不同.

1）主鍵索引：

MyISAM索引檔案和資料檔案是分離的，索引檔案僅儲存資料記錄的地址。而在InnoDB中，表資料檔案本身就是按B+Tree組織的一個索引結構，這棵樹的葉節點data域儲存了完整的資料記錄。這個索引的key是資料表的主鍵，因此InnoDB表資料檔案本身就是主索引。

               (圖inndb主鍵索引）

(圖inndb主鍵索引）是InnoDB主索引（同時也是資料檔案）的示意圖，可以看到葉節點包含了完整的資料記錄。這種索引叫做聚集索引。因為InnoDB的資料檔案本身要按主鍵聚集，所以InnoDB要求表必須有主鍵（MyISAM可以沒有），如果沒有顯式指定，則MySQL系統會自動選擇一個可以唯一標識資料記錄的列作為主鍵，如果不存在這種列，則MySQL自動為InnoDB表生成一個隱含欄位作為主鍵，這個欄位長度為6個位元組，型別為長整形。

2）. InnoDB的輔助索引

       InnoDB的所有輔助索引都引用主鍵作為data域。例如，下圖為定義在Col3上的一個輔助索引：

        InnoDB 表是基於聚簇索引建立的。因此InnoDB 的索引能提供一種非常快速的主鍵查詢效能。不過，它的輔助索引（Secondary Index， 也就是非主鍵索引）也會包含主鍵列，所以，如果主鍵定義的比較大，其他索引也將很大。如果想在表上定義 、很多索引，則爭取儘量把主鍵定義得小一些。InnoDB 不會壓縮索引。

      文字元的ASCII碼作為比較準則。聚集索引這種實現方式使得按主鍵的搜尋十分高效，但是輔助索引搜尋需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然後用主鍵到主索引中檢索獲得記錄。

      不同儲存引擎的索引實現方式對於正確使用和優化索引都非常有幫助，例如知道了InnoDB的索引實現後，就很容易明白為什麼不建議使用過長的欄位作為主鍵，因為所有輔助索引都引用主索引，過長的主索引會令輔助索引變得過大。再例如，用非單調的欄位作為主鍵在InnoDB中不是個好主意，因為InnoDB資料檔案本身是一顆B+Tree，非單調的主鍵會造成在插入新記錄時資料檔案為了維持B+Tree的特性而頻繁的分裂調整，十分低效，而使用自增欄位作為主鍵則是一個很好的選擇。

InnoDB索引和MyISAM索引的區別：

一是主索引的區別，InnoDB的資料檔案本身就是索引檔案。而MyISAM的索引和資料是分開的。

二是輔助索引的區別：InnoDB的輔助索引data域儲存相應記錄主鍵的值而不是地址。而MyISAM的輔助索引和主索引沒有多大區別。