B树和B+树

最新推荐文章于 2024-10-26 22:50:34 发布

原创最新推荐文章于 2024-10-26 22:50:34 发布 · 415 阅读

0 ·

CC 4.0 BY-SA版权

数据结构专栏收录该内容

20 篇文章

订阅专栏

本文深入解析了B树和B+树的概念，详细阐述了它们在数据库索引中的应用，特别是MySQL的InnoDB和MyISAM存储引擎如何利用B+树优化数据访问速度。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

B树的定义:

Plus版——B+树

MySQL是如何使用B树的

B树的定义:

一种适用于外查找的树，它是一种平衡的多叉树，称为B树，其定义如下：
一棵m阶的B树满足下列条件：

树中每个结点至多有m个孩子；
除根结点和叶子结点外，其它每个结点至少有m/2个孩子；
若根结点不是叶子结点，则至少有2个孩子；
所有叶子结点都出现在同一层，叶子结点不包含任何关键字信息；
有k个孩子的非终端结点恰好包含有k-1个关键字。

   在B树中，每个结点中关键字从小到大排列，并且当该结点的孩子是非叶子结点时，该k-1个关键字正好是k个孩子包含的关键字的值域的分划。
   因为叶子结点不包含关键字，所以可以把叶子结点看成在树里实际上并不存在外部结点，指向这些外部结点的指针为空，叶子结点的数目正好等于树中所包含的关键字总个数加1。
   B树中的一个包含n个关键字，n+1个指针的结点的一般形式为：（n,P0,K1,P1,K2,P2,…,Kn,Pn）
   其中，Ki为关键字，K1<K2<…<Kn, Pi 是指向包括Ki到Ki+1之间的关键字的子树的指针。

2. B树的查找:
   在B树中查找给定关键字的方法是，首先把根结点取来，在根结点所包含的关键字K1,…,kj查找给定的关键字（可用顺序查找或二分查找法），若找到等于给定值的关键字，则查找成功；否则，一定可以确定要查的关键字在某个Ki或Ki+1之间，于是取Pi所指的结点继续查找，直到找到，或指针Pi为空时查找失败。
   查找算法演示
   性能分析：
  设B树包含N个关键字，因此有N+1个叶子结点，叶子都在第I层（最底层）。因为根至少有两个孩子，因此第二层至少有两个结点。除根和叶子外，其它结点至少有┌m/2┐个孩子，因此在第三层至少有2*┌m/2┐个结点，在第四层至少有2*┌m/2┐2个结点，．．．，在第I层至少有2*┌m/2┐I-1 个结点，于是有：
   N+1 ≥ 2*┌m/2┐I-1
   即： I ≥ log┌m/2┐(
   这个公式保证了B树的查找效率是相当高的。

3. B树的插入:
  当在叶子结点处于第L+1层的B树中插入关键字时，被插入的关键字总是进入第L层的结点。

若在一个包含j<m-1个关键字的结点中插入一个新的关键字，则把新的关键字直接插入该结点即可；
但若把一个新的关键字插入到包含m-1（m为B树的阶）个关键字的结点中，则将引起结点的分裂。在这种情况下，要把这个结点分裂为两个，并把中间的一个关键字拿出来插到该结点的双亲结点中去，双亲结点也可能是满的，就需要再分裂、再往上插，从而可能导致B树可能朝着根的方向生长。

4. B树的删除:
当从B树中删除一个关键字Ki时，总的分为以下两种情况：

如果该关键字所在的结点不是最下层的非叶子结点，则先需要把此关键字与它在B树中后继对换位置，即以指针Pi所指子树中的最小关键字Y代替Ki，然后在相应的结点中删除Y。
如果该关键字所在的结点正好是最下层的非叶子结点，这种情况下，会有以下两种可能：
1. 若该关键字Ki所在结点中的关键字个数不小于┌m/2┐，则可以直接从该结点中删除该关键字和相应指针即可。
2. 若该关键字Ki所在结点中的关键字个数小于┌m/2┐，则直接从结点中删除关键字会导致此结点中所含关键字个数小于┌m/2┐-1 。这种情况下，需考察该结点在B树中的左或右兄弟结点，从兄弟结点中移若干个关键字到该结点中来（这也涉及它们的双亲结点中的一个关键字要作相应变化），使两个结点中所含关键字个数基本相同；但如果其兄弟结点的关键字个数也很少，刚好等于┌m/2┐-1 ，这种移动则不能进行，这种情形下，需要把删除了关键字Ki的结点、它的兄弟结点及它们双亲结点中的一个关键字合并为一个结点。

Plus版——B+树

作为B树的加强版，B+树与B树的差异在于

有n棵子树的节点含有n个关键字（也有认为是n-1个关键字）
所有的叶子节点包含了全部的关键字，及指向含这些关键字记录的指针，且叶子节点本身根据关键字自小而大顺序连接
非叶子节点可以看成索引部分，节点中仅含有其子树（根节点）中的最大（或最小）关键字

B+树的查找过程，与B树类似，只不过查找时，如果在非叶子节点上的关键字等于给定值，并不终止，而是继续沿着指针直到叶子节点位置。因此在B+树，不管查找成功与否，每次查找都是走了一条从根到叶子节点的路径。

MySQL是如何使用B树的

说明：事实上，在MySQL数据库中，诸多存储引擎使用的是B+树，即便其名字看上去是BTREE。

1、innodb的索引机制

先以innodb存储引擎为例，说明innodb引擎是如何利用B+树建立索引的。首先创建一张表：zodiac，并插入一些数据

CREATE TABLE `zodiac` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` char(4) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `index_name` (`name`)
); 

insert zodiac(id,name) values(1,'鼠'); &nbsp;
insert zodiac(id,name) values(2,'牛'); &nbsp;
insert zodiac(id,name) values(3,'虎'); &nbsp;
insert zodiac(id,name) values(4,'兔'); &nbsp;
insert zodiac(id,name) values(5,'龙'); &nbsp;
insert zodiac(id,name) values(6,'蛇'); &nbsp;
insert zodiac(id,name) values(7,'马'); &nbsp;
insert zodiac(id,name) values(8,'羊'); &nbsp;
insert zodiac(id,name) values(9,'猴');
insert zodiac(id,name) values(10,'鸡'); &nbsp;
insert zodiac(id,name) values(11,'狗'); &nbsp;
insert zodiac(id,name) values(12,'猪');

对于innodb来说，只有一个数据文件，这个数据文件本身就是用B+树形式组织，B+树每个节点的关键字就是表的主键，因此innodb的数据文件本身就是主索引文件，如下图所示，主索引中的叶子页（leaf page）包含了数据记录，但非叶子节点只包含了主键，术语“聚簇”表示数据行和相邻的键值紧凑地存储在一起，因此这种索引被称为聚簇索引，或聚集索引。

这种索引方式，可以提高数据访问的速度，因为索引和数据是保存在同一棵B树之中，从聚簇索引中获取数据通常比在非聚簇索引中要来得快。

所以可以说，innodb的数据文件是依靠主键组织起来的，这也就是为什么innodb引擎下创建的表，必须指定主键的原因，如果没有显式指定主键，innodb引擎仍然会对该表隐式地定义一个主键作为聚簇索引。

同样innodb的辅助索引，如下图所示，假设这些字符是按照生肖的顺序排列的（其实我也不知道具体怎么实现，不要在意这些细节，就是举个例子），其叶子节点中也包含了记录的主键，因此innodb引擎在查询辅助索引的时候会查询两次，首先通过辅助索引得到主键值，然后再查询主索引，略微有点啰嗦。。。

2、MyISAM的索引机制

MyISAM引擎同样也使用B+树组织索引，如下图所示，假设我们的数据不是按照之前的顺序插入的，而是按照图中的是顺序插入表，可以看到MyISAM引擎下，B+树叶子节点中包含的是数据记录的地址（可以简单理解为“行号”），而MyISAM的辅助索引在结构上和主索引没有本质的区别，同样其叶子节点也包含了数据记录的地址，稍微不同的是辅助索引的关键字是允许重复。

六、简单对比

1、Innodb辅助索引的叶子节点存储的不是地址，而是主键值，这样的策略减少了当出现行移动或者数据页分裂时辅助索引的维护工作，虽然使用主键值当作指针会让辅助索引占用更多空间，但好处是，Innodb在移动行时无需更新辅助索引中的主键值，而MyISAM需要调整其叶子节点中的地址。

2、innodb引擎下，数据记录是保存在B+树的叶子节点（大小相当于磁盘上的页）上，当插入新的数据时，如果主键的值是有序的，它会把每一条记录都存储在上一条记录的后面，但是如果主键使用的是无序的数值，例如UUID，这样在插入数据时Innodb无法简单地把新的数据插入到最后，而是需要为这条数据寻找合适的位置，这就额外增加了工作，这就是innodb引擎写入性能要略差于MyISAM的原因之一。

Innodb和MyISAM索引的抽象图