數據庫_四大索引、聚焦、非聚焦詳解

一. 四種索引(主鍵索引/普通索引/全文索引/唯一索引)

1.索引的添加 

1.1主鍵索引

當一張表，把某個列設爲主鍵的時候，則該列就是主鍵索引

create table a(
id int primary key auto_increment,
name varchar(20) not null default ''
);
//這裏id就是表的主鍵

如果當創建表時沒有指定主鍵索引，也可以在創建表之後添加：

alter table table_name add primary key (column name);

1.2普通索引

普通索引一般是在建表後再添加的，

create index  索引名  on table_name(column1,column2);

alter table table_name add index 索引名(column1,column2);

1.3全文索引

首先，全文索引主要針對文本文件，比如文章，標題，全文索引只有MyISAM有效(mysql5.6之後InnoDB也支持了全文索引)

create table c(
id int primary key auto_increment ,
title varchar(20),
content text,
fulltext(title,content)
)engine=myisam charset utf8;

insert into c(title,content) values
    ('MySQL Tutorial','DBMS stands for DataBase ...'),
    ('How To Use MySQL Well','After you went through a ...'),
    ('Optimizing MySQL','In this tutorial we will show ...'),
    ('1001 MySQL Tricks','1. Never run mysqld as root. 2. ...'),
    ('MySQL vs. YourSQL','In the following database comparison ...'),
    ('MySQL Security','When configured properly, MySQL ...');

使用全文索引常見的錯誤：

select * from c where content like "%mysql%";

這裏並不會使用全文索引，可以用explain進行查看。正確用法：

select *  from c where match(title,content) against ('MYSQL');

備註:

1.  在mysql中fulltext 索引只針對 myisam生效

2.  mysql自己提供的fulltext針對英文生效->sphinx(coreseek)技術處理中文

3.  使用方法是 match(字段名..) against(‘關鍵字’)

1.4唯一索引

create table d(id int primary key auto_increment , name varchar(32) unique)

d表中name就是唯一索引，唯一索引可以有多個null,不能是重複的內容

相比主鍵索引，主鍵字段不能爲null，也不能重複，不能設爲外鍵

主鍵本質是約束，值不爲空，一個表只能建一個，其目的是檢查數據的正確性

唯一索引本質是索引，值可爲空，一個表能建一多個，其目的是實現數據查詢的優化

唯一約束本質是約束，值可爲空，一個表能建一多個，其目的是檢查數據的正確性

主鍵是唯一的，所以創建了一個主鍵的同時，也就這個字段創建了一個唯一的索引，
唯一索引實際上就是要求指定的列中所有的數據必須不同。

主鍵一唯一索引的區別：
         1 一個表的主鍵只能有一個，而唯一索引可以建多個。
         2 主鍵可以作爲其它表的外鍵。
         3 主鍵不可爲null，唯一索引可以爲null。

2. 查詢索引

show indexes from table_name;

show keys from table_name;

3.刪除索引

alter table table_name drop index 索引名;

二. 索引的機制

2.1 索引的優點

在我們添加完索引之後，mysql一般通過BTREE算法生成一個索引文件，在查詢數據庫時，找到索引文件進行遍歷(折半查找大幅查詢效率)，找到相應的鍵從而獲取數據。

1，通過創建唯一性索引，可以保證數據庫表中每一行數據的唯一性。
2，可以大大加快數據的檢索速度，這也是創建索引的最主要的原因。
3，可以加速表和表之間的連接，特別是在實現數據的參考完整性方面特別有意義。
4，在使用分組和排序子句進行數據檢索時，同樣可以顯著減少查詢中分組和排序的時間。
5，通過使用索引，可以在查詢的過程中，使用優化隱藏器，提高系統的性能

2.2 索引的代價

1. 增加了數據庫的存儲空間

2. 在插入和修改數據時要花費較多的時間

2.3 在哪些column上使用索引？

1. 較頻繁的作爲查詢條件字段應該創建索引 

2. 唯一性太差的字段不適合創建索引，儘管頻繁作爲查詢條件，例如，gender性別字段

3. 更新非常頻繁的字段不適合作爲索引

4. 不會出現在where子句中的字段不該創建索引

總結: 滿足以下條件的字段，才應該創建索引.

a: 在經常使用在where子句的列 

b: 該字段的內容不是唯一的幾個值 

c: 字段內容不是頻繁變化

三.索引使用注意事項

1.對於創建的多列索引，只要查詢條件使用了最左邊的列，索引一般就會被使用。

比如我們對title,content 添加了複合索引

select * from table_name where title = 'test';會用到索引

select * from table_name where content = 'test';不會用到索引

2.對於使用like的查詢，查詢如果是 ‘%a’不會使用到索引 ,而 like 'a%'就會用到索引。最前面不能使用%和_這樣的變化值

3.如果條件中有or，即使其中有條件帶索引也不會使用。

4.如果列類型是字符串，那一定要在條件中將數據使用引號引用起來。

四.如何查看索引使用的情況:

show status like‘Handler_read%’;

注意： 

handler_read_key:這個值越高越好，越高表示使用索引查詢到的次數。

handler_read_rnd_next:這個值越高，說明查詢低效。

一、索引的作用

1、幫助檢索數據；

2、提高聯接效率；

3、節省ORDER BY、GROUP BY的時間；

4、保證數據唯一性（僅限於唯一索引）。

二、索引的設計

在確定要建立一個索引時，首先我們要確定它是聚集還是非聚集、單列還是多列、唯一還是非唯一、列是升序還是降序、它的存儲是如何的，比如：分區、填充因子等。下面逐條來看：

1、聚集索引

（1）首先指出一個誤區，主鍵並不一定是聚集索引，只是在SQL SERVER中，未明確指出的情況下，默認將主鍵定義爲聚集，而ORACLE中則默認是非聚集，因爲SQL SERVER中的ROWID未開放使用。

（2）聚集索引適合用於需要進行範圍查找的列，因爲聚集索引的葉子節點存放的是有序的數據行，查詢引擎可根據WHERE中給出的範圍，直接定位到兩端的葉子節點，將這部分節點頁的數據根據鏈表順序取出即可；

（3）聚集索引儘量建立在值不會發生變更的列上，否則會帶來非聚集索引的維護；

（4）儘量在建立非聚集索引之前建立聚集索引，否則會導致表上所有非聚集索引的重建；

（5）聚集索引應該避免建立在數值單調的列上，否則可能會造成IO的競爭，以及B樹的不平衡，從而導致數據庫系統頻繁的維護B樹的平衡性。聚集索引的列值最好能夠在表中均勻分佈。

3、唯一索引

（1）再指出一個誤區，聚集索引並不一定是唯一索引，由於SQL SERVER將主鍵默認定義爲聚集索引，事實上，索引是否唯一與是否聚集是不相關的，聚集索引可以是唯一索引，也可以是非唯一索引；

（2）將索引設置爲唯一，對於等值查找是很有利的，當查到第一條符合條件的紀錄時即可停止查找，返回數據，而非唯一索引則要繼續查找，同樣，由於需要保證唯一性，每一行數據的插入都會去檢查重複性；

轉自：http://blog.csdn.net/u013927110/article/details/46636765

     http://blog.csdn.net/mr_zy58/article/details/24579861

• 爲什麼要給表加上主鍵？

• 爲什麼加索引後會使查詢變快？

• 爲什麼加索引後會使寫入、修改、刪除變慢？

• 什麼情況下要同時在兩個字段上建索引？

按照存儲方式分爲：聚集與非聚集索引

聚集索引:表中存儲的數據按照索引的順序存儲,檢索效率比普通索引高,但對數據新增/修改/刪除的影響比較大。邏輯順序決定了表中相應行的物理順序。
特點：
　 (1) 一個表可以最多可以創建249個索引
　 (2) 先建聚集索引才能創建非聚集索引
     (3) 非聚集索引數據與索引不同序
     (4) 數據與索引在不同位置
     (5) 索引在葉節點上存儲,在葉節點上有一個＂指針＂直接指向要查詢的數據區域
     (6) 數據不會根據索引鍵的順序重新排列數據

     (7)如果在該字段上進行範圍查詢，或者該表很少做增刪改

創建聚集索引的語法：
   create NONCLUSTERED INDEX idximpID ON EMP(empID)
非聚集索引:不影響表中的數據存儲順序,檢索效率比聚集索引低,對數據新增/修改/刪除的影響很少
。是通過二叉樹的數據結構來描述的，邏輯順序，特點：
   (1) 無索引，數據無序
   (2) 有索引，數據與索引同序 
   (3) 數據會根據索引鍵的順序重新排列數據
   (4) 一個表只能有一個索引
   (5) 葉節點的指針指向的數據也在同一位置存儲
語法：
create CLUSTERED INDEX idxempID on emp(empID)

想要理解索引原理必須清楚一種數據結構「平衡樹」(非二叉)，也就是b tree或者 b+ tree，重要的事情說三遍：“平衡樹，平衡樹，平衡樹”。當然， 有的數據庫也使用哈希桶作用索引的數據結構 ， 然而， 主流的RDBMS都是把平衡樹當做數據表默認的索引數據結構的。

我們平時建表的時候都會爲表加上主鍵， 在某些關係數據庫中， 如果建表時不指定主鍵，數據庫會拒絕建表的語句執行。 事實上， 一個加了主鍵的表，並不能被稱之爲「表」。一個沒加主鍵的表，它的數據無序的放置在磁盤存儲器上，一行一行的排列的很整齊， 跟我認知中的「表」很接近。如果給表上了主鍵，那麼表在磁盤上的存儲結構就由整齊排列的結構轉變成了樹狀結構，也就是上面說的「平衡樹」結構，換句話說，就是整個表就變成了一個索引。沒錯， 再說一遍， 整個表變成了一個索引，也就是所謂的「聚集索引」。 這就是爲什麼一個表只能有一個主鍵， 一個表只能有一個「聚集索引」，因爲數據行本身只能按一個順序存儲。，因爲主鍵的作用就是把「表」的數據格式轉換成「索引（平衡樹）」的格式放置。

上圖就是帶有主鍵的表（聚集索引）的結構圖。圖畫的不是很好， 將就着看。其中樹的所有結點（底部除外）的數據都是由主鍵字段中的數據構成，也就是通常我們指定主鍵的id字段。最下面部分是真正表中的數據。 假如我們執行一個SQL語句：

select * from table where id = 1256;

首先根據索引定位到1256這個值所在的葉結點，然後再通過葉結點取到id等於1256的數據行。 這裏不講解平衡樹的運行細節， 但是從上圖能看出，樹一共有三層， 從根節點至葉節點只需要經過三次查找就能得到結果。如下圖

假如一張表有一億條數據 ，需要查找其中某一條數據，按照常規邏輯， 一條一條的去匹配的話， 最壞的情況下需要匹配一億次才能得到結果，用大O標記法就是O(n)最壞時間複雜度，這是無法接受的，而且這一億條數據顯然不能一次性讀入內存供程序使用， 因此， 這一億次匹配在不經緩存優化的情況下就是一億次IO開銷，以現在磁盤的IO能力和CPU的運算能力， 有可能需要幾個月才能得出結果 。如果把這張錶轉換成平衡樹結構（一棵非常茂盛和節點非常多的樹），假設這棵樹有10層，那麼只需要10次IO開銷就能查找到所需要的數據， 速度以指數級別提升，用大O標記法就是O(log n)，n是記錄總樹，底數是樹的分叉數，結果就是樹的層次數。換言之，查找次數是以樹的分叉數爲底，記錄總數的對數，用公式來表示就是

用程序來表示就是Math.Log(100000000,10)，100000000是記錄數，10是樹的分叉數（真實環境下分叉數遠不止10）， 結果就是查找次數，這裏的結果從億降到了個位數。因此，利用索引會使數據庫查詢有驚人的性能提升。

然而， 事物都是有兩面的， 索引能讓數據庫查詢數據的速度上升， 而使寫入數據的速度下降，原因很簡單的， 因爲平衡樹這個結構必須一直維持在一個正確的狀態， 增刪改數據都會改變平衡樹各節點中的索引數據內容，破壞樹結構， 因此，在每次數據改變時， DBMS必須去重新梳理樹（索引）的結構以確保它的正確，這會帶來不小的性能開銷，也就是爲什麼索引會給查詢以外的操作帶來副作用的原因。

講完聚集索引 ， 接下來聊一下非聚集索引， 也就是我們平時經常提起和使用的常規索引。

非聚集索引和聚集索引一樣， 同樣是採用平衡樹作爲索引的數據結構。索引樹結構中各節點的值來自於表中的索引字段，假如給user表的name字段加上索引，那麼索引就是由name字段中的值構成，在數據改變時， DBMS需要一直維護索引結構的正確性。如果給表中多個字段加上索引，那麼就會出現多個獨立的索引結構，每個索引（非聚集索引）互相之間不存在關聯。 如下圖

每次給字段建一個新索引， 字段中的數據就會被複制一份出來， 用於生成索引。 因此， 給表添加索引，會增加表的體積， 佔用磁盤存儲空間。

非聚集索引和聚集索引的區別在於，通過聚集索引可以查到需要查找的數據， 而通過非聚集索引可以查到記錄對應的主鍵值 ，再使用主鍵的值通過聚集索引查找到需要的數據，如下圖

不管以任何方式查詢表， 最終都會利用主鍵通過聚集索引來定位到數據， 聚集索引（主鍵）是通往真實數據所在的唯一路徑。

然而， 有一種例外可以不使用聚集索引就能查詢出所需要的數據， 這種非主流的方法 稱之爲「覆蓋索引」查詢， 也就是平時所說的複合索引或者多字段索引查詢。 文章上面的內容已經指出， 當爲字段建立索引以後， 字段中的內容會被同步到索引之中， 如果爲一個索引指定兩個字段， 那麼這個兩個字段的內容都會被同步至索引之中。

先看下面這個SQL語句

//建立索引

create clustered index index_birthday on user_info(birthday);

//查詢生日在1991年11月1日出生用戶的用戶名

select user_name from user_info where birthday = '1991-11-1'

這句SQL語句的執行過程如下

首先，通過非聚集索引index_birthday查找birthday等於1991-11-1的所有記錄的主鍵ID值

然後，通過得到的主鍵ID值執行聚集索引查找，找到主鍵ID值對就的真實數據（數據行）存儲的位置

最後， 從得到的真實數據中取得user_name字段的值返回， 也就是取得最終的結果

我們把birthday字段上的索引改成雙字段的覆蓋索引

create index index_birthday_and_user_name on user_info(birthday, user_name);

這句SQL語句的執行過程就會變爲

通過非聚集索引index_birthday_and_user_name查找birthday等於1991-11-1的葉節點的內容，然而，葉節點中除了有user_name表主鍵ID的值以外， user_name字段的值也在裏面， 因此不需要通過主鍵ID值的查找數據行的真實所在， 直接取得葉節點中user_name的值返回即可。 通過這種覆蓋索引直接查找的方式， 可以省略不使用覆蓋索引查找的後面兩個步驟， 大大的提高了查詢性能，如下圖

何時使用聚集索引或非聚集索引

下面的表總結了何時使用聚集索引或非聚集索引（很重要）：

 

動作描述	使用聚集索引	使用非聚集索引
列經常被分組排序	應	應
返回某範圍內的數據	應	不應
一個或極少不同值	不應	不應
小數目的不同值	應	不應
大數目的不同值	不應	應
頻繁更新的列	不應	應
外鍵列	應	應
主鍵列	應	應
頻繁修改索引列	不應	應

轉自：http://www.cnblogs.com/aspwebchh/p/6652855.html

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的輔助索引和主索引沒有多大區別。

轉自：http://blog.csdn.net/u012422829/article/details/45060827

B樹

       即二叉搜索樹：

       1.所有非葉子結點至多擁有兩個兒子（Left和Right）；

       2.所有結點存儲一個關鍵字；

       3.非葉子結點的左指針指向小於其關鍵字的子樹，右指針指向大於其關鍵字的子樹；

       如：

       

       B樹的搜索，從根結點開始，如果查詢的關鍵字與結點的關鍵字相等，那麼就命中；

否則，如果查詢關鍵字比結點關鍵字小，就進入左兒子；如果比結點關鍵字大，就進入

右兒子；如果左兒子或右兒子的指針爲空，則報告找不到相應的關鍵字；

       如果B樹的所有非葉子結點的左右子樹的結點數目均保持差不多（平衡），那麼B樹

的搜索性能逼近二分查找；但它比連續內存空間的二分查找的優點是，改變B樹結構

（插入與刪除結點）不需要移動大段的內存數據，甚至通常是常數開銷；

       如：

      

   但B樹在經過多次插入與刪除後，有可能導致不同的結構：

   右邊也是一個B樹，但它的搜索性能已經是線性的了；同樣的關鍵字集合有可能導致不同的

樹結構索引；所以，使用B樹還要考慮儘可能讓B樹保持左圖的結構，和避免右圖的結構，也就

是所謂的“平衡”問題；      

       實際使用的B樹都是在原B樹的基礎上加上平衡算法，即“平衡二叉樹”；如何保持B樹

結點分佈均勻的平衡算法是平衡二叉樹的關鍵；平衡算法是一種在B樹中插入和刪除結點的

策略；

 

 

B-樹

       是一種多路搜索樹（並不是二叉的）：

       1.定義任意非葉子結點最多隻有M個兒子；且M>2；

       2.根結點的兒子數爲[2, M]；

       3.除根結點以外的非葉子結點的兒子數爲[M/2, M]；

       4.每個結點存放至少M/2-1（取上整）和至多M-1個關鍵字；（至少2個關鍵字）

       5.非葉子結點的關鍵字個數=指向兒子的指針個數-1；

       6.非葉子結點的關鍵字：K[1], K[2], …, K[M-1]；且K[i] < K[i+1]；

       7.非葉子結點的指針：P[1], P[2], …, P[M]；其中P[1]指向關鍵字小於K[1]的

子樹，P[M]指向關鍵字大於K[M-1]的子樹，其它P[i]指向關鍵字屬於(K[i-1], K[i])的子樹；

       8.所有葉子結點位於同一層；

       如：（M=3）

       B-樹的搜索，從根結點開始，對結點內的關鍵字（有序）序列進行二分查找，如果

命中則結束，否則進入查詢關鍵字所屬範圍的兒子結點；重複，直到所對應的兒子指針爲

空，或已經是葉子結點；

B-樹的特性：

       1.關鍵字集合分佈在整顆樹中；

       2.任何一個關鍵字出現且只出現在一個結點中；

       3.搜索有可能在非葉子結點結束；

       4.其搜索性能等價於在關鍵字全集內做一次二分查找；

       5.自動層次控制；

       由於限制了除根結點以外的非葉子結點，至少含有M/2個兒子，確保了結點的至少

利用率，其最底搜索性能爲：

    

       其中，M爲設定的非葉子結點最多子樹個數，N爲關鍵字總數；

       所以B-樹的性能總是等價於二分查找（與M值無關），也就沒有B樹平衡的問題；

       由於M/2的限制，在插入結點時，如果結點已滿，需要將結點分裂爲兩個各佔

M/2的結點；刪除結點時，需將兩個不足M/2的兄弟結點合併；

 

 

B+樹

       B+樹是B-樹的變體，也是一種多路搜索樹：

       1.其定義基本與B-樹同，除了：

       2.非葉子結點的子樹指針與關鍵字個數相同；

       3.非葉子結點的子樹指針P[i]，指向關鍵字值屬於[K[i], K[i+1])的子樹

（B-樹是開區間）；

       5.爲所有葉子結點增加一個鏈指針；

       6.所有關鍵字都在葉子結點出現；

       如：（M=3）

   B+的搜索與B-樹也基本相同，區別是B+樹只有達到葉子結點才命中（B-樹可以在

非葉子結點命中），其性能也等價於在關鍵字全集做一次二分查找；

       B+的特性：

       1.所有關鍵字都出現在葉子結點的鏈表中（稠密索引），且鏈表中的關鍵字恰好

是有序的；

       2.不可能在非葉子結點命中；

       3.非葉子結點相當於是葉子結點的索引（稀疏索引），葉子結點相當於是存儲

（關鍵字）數據的數據層；

       4.更適合文件索引系統；

  

B*樹

       是B+樹的變體，在B+樹的非根和非葉子結點再增加指向兄弟的指針；

   B*樹定義了非葉子結點關鍵字個數至少爲(2/3)*M，即塊的最低使用率爲2/3

（代替B+樹的1/2）；

       B+樹的分裂：當一個結點滿時，分配一個新的結點，並將原結點中1/2的數據

複製到新結點，最後在父結點中增加新結點的指針；B+樹的分裂隻影響原結點和父

結點，而不會影響兄弟結點，所以它不需要指向兄弟的指針；

       B*樹的分裂：當一個結點滿時，如果它的下一個兄弟結點未滿，那麼將一部分

數據移到兄弟結點中，再在原結點插入關鍵字，最後修改父結點中兄弟結點的關鍵字

（因爲兄弟結點的關鍵字範圍改變了）；如果兄弟也滿了，則在原結點與兄弟結點之

間增加新結點，並各複製1/3的數據到新結點，最後在父結點增加新結點的指針；

       所以，B*樹分配新結點的概率比B+樹要低，空間使用率更高； 

小結

       B樹：二叉樹，每個結點只存儲一個關鍵字，等於則命中，小於走左結點，大於

走右結點；

       B-樹：多路搜索樹，每個結點存儲M/2到M個關鍵字，非葉子結點存儲指向關鍵

字範圍的子結點；

       所有關鍵字在整顆樹中出現，且只出現一次，非葉子結點可以命中；

       B+樹：在B-樹基礎上，爲葉子結點增加鏈表指針，所有關鍵字都在葉子結點

中出現，非葉子結點作爲葉子結點的索引；B+樹總是到葉子結點才命中；

       B*樹：在B+樹基礎上，爲非葉子結點也增加鏈表指針，將結點的最低利用率

從1/2提高到2/3；

轉自：https://www.cnblogs.com/oldhorse/archive/2009/11/16/1604009.html