关于索引的B tree B-tree B+tree B*tree 详解结构图

ゞ浴缸里的玫瑰 2022-05-27 10:23 122阅读 0赞

B树

即二叉搜索树：

1.所有非叶子结点至多拥有两个儿子（Left和Right）；

2.所有结点存储一个关键字；

3.非叶子结点的左指针指向小于其关键字的子树，右指针指向大于其关键字的子树；

如：

![1.JPG][]

B树的搜索，从根结点开始，如果查询的关键字与结点的关键字相等，那么就命中；

否则，如果查询关键字比结点关键字小，就进入左儿子；如果比结点关键字大，就进入

右儿子；如果左儿子或右儿子的指针为空，则报告找不到相应的关键字；

如果B树的所有非叶子结点的左右子树的结点数目均保持差不多（平衡），那么B树

的搜索性能逼近二分查找；但它比连续内存空间的二分查找的优点是，改变B树结构

（插入与删除结点）不需要移动大段的内存数据，甚至通常是常数开销；

如：

![2.JPG][]

但B树在经过多次插入与删除后，有可能导致不同的结构：

![31.JPG][]

右边也是一个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）

![4.JPG][]

B-树的搜索，从根结点开始，对结点内的关键字（有序）序列进行二分查找，如果

命中则结束，否则进入查询关键字所属范围的儿子结点；重复，直到所对应的儿子指针为

空，或已经是叶子结点；

B-树的特性：

1.关键字集合分布在整颗树中；

2.任何一个关键字出现且只出现在一个结点中；

3.搜索有可能在非叶子结点结束；

4.其搜索性能等价于在关键字全集内做一次二分查找；

5.自动层次控制；

由于限制了除根结点以外的非叶子结点，至少含有M/2个儿子，确保了结点的至少

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

![0.JPG][]

其中，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）

![5.JPG][]

B+的搜索与B-树也基本相同，区别是B+树只有达到叶子结点才命中（B-树可以在

非叶子结点命中），其性能也等价于在关键字全集做一次二分查找；

B+的特性：

1.所有关键字都出现在叶子结点的链表中（稠密索引），且链表中的关键字恰好

是有序的；

2.不可能在非叶子结点命中；

3.非叶子结点相当于是叶子结点的索引（稀疏索引），叶子结点相当于是存储

（关键字）数据的数据层；

4.更适合文件索引系统；

B\*树

是B+树的变体，在B+树的非根和非叶子结点再增加指向兄弟的指针；

![6.JPG][]

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；

MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址。下图是MyISAM索引的原理图：

![20121130111257402.png][]

这里设表一共有三列，假设我们以Col1为主键，则上图是一个MyISAM表的主索引（Primary key）示意。可以看出MyISAM的索引文件仅仅保存数据记录的地址。在MyISAM中，主索引和辅助索引（Secondary key）在结构上没有任何区别，只是主索引要求key是唯一的，而辅助索引的key可以重复。如果我们在Col2上建立一个辅助索引，则此索引的结构如下图所示：

![20121130111258238.png][]

同样也是一颗B+Tree，data域保存数据记录的地址。因此，MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。

MyISAM的索引方式也叫做“非聚集”的，之所以这么称呼是为了与InnoDB的聚集索引区分。

InnoDB索引实现

虽然InnoDB也使用B+Tree作为索引结构，但具体实现方式却与MyISAM截然不同。

第一个重大区别是InnoDB的数据文件本身就是索引文件。从上文知道，MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。而在InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。

![20121130111259913.png][]

上图是InnoDB主索引（同时也是数据文件）的示意图，可以看到叶节点包含了完整的数据记录。这种索引叫做聚集索引。因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有），如果没有显式指定，则MySQL [系统][Link 1]会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。

第二个与MyISAM索引的不同是InnoDB的辅助索引data域存储相应记录主键的值而不是地址。换句话说，InnoDB的所有辅助索引都引用主键作为data域。例如，下图为定义在Col3上的一个辅助索引：

![20121130111300494.png][]

这里以英文字符的ASCII码作为比较准则。聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。

了解不同存储引擎的索引实现方式对于正确使用和优化索引都非常有帮助，例如知道了InnoDB的索引实现后，就很容易明白为什么不建议使用过长的字段作为主键，因为所有辅助索引都引用主索引，过长的主索引会令辅助索引变得过大。再例如，用 非单调(可能是指“非递增”的意思)的字段作为主键在InnoDB中不是个好主意，因为InnoDB数据文件本身是一颗B+Tree， 非单调(可能是指“非递增”的意思)的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。

[http://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html][http_www.cnblogs.com_hustcat_archive_2009_10_28_1591648.html]

[http://blog.csdn.net/zuiaituantuan/article/details/5909334][http_blog.csdn.net_zuiaituantuan_article_details_5909334]

[http://www.codinglabs.org/html/theory-of-mysql-index.html][http_www.codinglabs.org_html_theory-of-mysql-index.html]

[http://isky000.com/database/mysql\_order\_by\_implement][http_isky000.com_database_mysql_order_by_implement]

[http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html][http_dev.mysql.com_doc_refman_5.0_en_server-system-variables.html]

[http://www.docin.com/p-211669085.html][http_www.docin.com_p-211669085.html]

[1.JPG]: /images/20220527/c635c0860c9f4e7a96aac329a85b208a.png
[2.JPG]: /images/20220527/680fb6551aa34e13ba18a3b0833549fd.png
[31.JPG]: /images/20220527/32e99ed266a34d21a70d2d38a01c5aed.png
[4.JPG]: /images/20220527/4e71350b76ea4217b4051449a71f165d.png
[0.JPG]: /images/20220527/2424030cccbf43bf9229cf455f0d52fb.png
[5.JPG]: /images/20220527/5325763f22f64cedb1f76c90b429107c.png
[6.JPG]: /images/20220527/3d31fc4fd2dd4a0db5c88945603b628a.png
[20121130111257402.png]: http://up.2cto.com/2012/1130/20121130111257402.png
[20121130111258238.png]: http://up.2cto.com/2012/1130/20121130111258238.png
[20121130111259913.png]: http://up.2cto.com/2012/1130/20121130111259913.png
[Link 1]: http://www.2cto.com/os/
[20121130111300494.png]: http://up.2cto.com/2012/1130/20121130111300494.png
[http_www.cnblogs.com_hustcat_archive_2009_10_28_1591648.html]: http://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html
[http_blog.csdn.net_zuiaituantuan_article_details_5909334]: http://blog.csdn.net/zuiaituantuan/article/details/5909334
[http_www.codinglabs.org_html_theory-of-mysql-index.html]: http://www.codinglabs.org/html/theory-of-mysql-index.html
[http_isky000.com_database_mysql_order_by_implement]: http://isky000.com/database/mysql_order_by_implement
[http_dev.mysql.com_doc_refman_5.0_en_server-system-variables.html]: http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
[http_www.docin.com_p-211669085.html]: http://www.docin.com/p-211669085.html