数据库索引算法——B树与B+树

B-树

数据库索引为何要使用树结构存储呢？
这个还不简单，树的查询效率高，并且能够保持有序。
既然这样，为何索引没有使用二叉查找树来实现呢？
这就不明白了，明明二叉查找树时间复杂度是O(logN)，性能已经足够高了，难道B树能够比它更快？

其实从算法逻辑来说，二叉树查找树的查找速度和比较次数都是最小的，可是咱们不得不考虑一个现实问题：磁盘IO ；数据索引是存储在磁盘上的，当数据量比较大的时候，索引的大小可能有几个G甚至更多。
当咱们利用索引查询的时候，能把整个索引所有加载到内存吗？显然不可能。能作的只有逐一加载每一个磁盘页，这里的磁盘页对应索引树的节点。
在二叉查找树里，磁盘的IO次数等于索引树的高度。

既然如此，为了减小磁盘的IO次数，咱们就须要把本来“瘦高”的树结构变成“矮胖”，这是B-树的特征之一。
B-树是一种多路平衡查找树，它的每个节点最多包含k个孩子，k被称为B树的阶。
k的大小取决于磁盘页的大小。

下面来具体介绍如下B-树（Balance Tree），一个m阶的B树具备以下几个特征：

1. 根节点至少有两个子女；
2. 每一个中间节点都包含k-1个元素和k个孩子，其中m/2<=k<=m；
3. 每个叶子节点都包含k-1个元素，其中m/2<=k<=m；
4. 全部叶子节点都位于同一层；
5. 每一个节点中的元素从小到大排列，节点当中k-1个元素正好是k个孩子包含的元素的值域划分。

下面以3阶的B-树为例，来看看B-树的具体结构。

【     9    】
           /                  \
          /                    \
     【2  6】                 【12】
   /   |      \            /       \ 
  /    |       \          /        \ 
 /     |        \        /          \
1    【3 5】     8       11       【13 15】

这棵树中，重点看【2 6】节点，该节点有两个元素2和6，又有三个孩子1，【3 5】和8。
其中1小于元素2,6之间，8大于【3 5】，正好符合刚刚所列的几条特征。

演示下B-树的查询过程，假如咱们要查询数值为5的节点。
第一次IO，查到 9，比较9
第二次IO，查到 【2 6】 比较2，比较6
第三次IO，查到 【3 5】 比较3， 比较5

虽然 比较次数 并不比二叉查找树少，尤为当单一节点中的元素数量不少时。
可是相比磁盘IO的速度，内存中 比较的操做 耗时几乎能够忽略，因此只要树的高度足够低，IO次数足够少，就能够提升查找性能。
相比之下节点内部元素多一些并不要紧，最多就是几回内存交换操做而已，只要不超过磁盘页的大小，这就是B-树的优点之一。

但B-树，插入新节点的过程就比较复杂，并且分红不少种状况。因此咱们举个典型的例子，上图中插入4.
自顶下查找4的节点位置，发现4应该插入【3 5】之间
节点【3 5】已是两个元素节点，根据特征2要求，没法再增长了。父节点【2 6】也是两元素节点，也没法再增长，根节点9是单元素节点，能够升级为两元素节点。因而拆分节点【3 5】和节点【2 6】，让根节点升级为两元素节点【4 9】，节点6独立成为根节点的第二个孩子。

【    4 9    】
         /         |         \
        /          |          \
       2          6          【12】
   /   |         / \        /      \ 
  /    |        /   \      /        \ 
 /     |       /     \    /          \
1      3      5       8  11       【13 15】

虽然维护树结构麻烦，但也正由于如此，让B-树可以始终维持多路平衡。这就是B-树的一大优点：自平衡。

下面在举例说说B-树的删除，继续上一颗树，咱们要删除元素11
自顶向下查找元素11的节点位置。
删除11后，节点12只有一个孩子，不符合特征1和5 （很差意思，我猜的，原文就直说不符合B树规范）。
所以找出12，13，15这个节点的中位数，取代节点12，而节点12自身下已成为第一个孩子。（此过程为左旋）

【    4 9    】
         /         |         \
        /          |          \
       2          6            13
   /   |         / \        /      \ 
  /    |        /   \      /        \ 
 /     |       /     \    /          \
1      3      5       8  12          15

虽然B-树的插入和删除，很复杂，没看懂也不要紧，关键是理解B-树的核心思想：B-树主要应用于文件系统以及部分数据库索引，好比著名的非关系型数据库MongoDB。

不过大部分关系型数据库，好比MySql，则使用B+树做为索引。

不少文档里，有时写B-树，有些写B树，但都是指balance tree，而不是balance binary tree

B+树

B+树是基于B-树的一种变体，有着比B-树更高的查询性能。

一个m阶的B+树具备以下几个特征：

1. 有k个子树的中间节点包含k个元素（B-树中是k-1个元素），每一个元素不保存数据，只用来索引，全部数据都保存在叶子节点。
2. 全部叶子节点中包含了所有元素的信息，及指向含这些元素记录的指针，且叶子节点自己 按关键字的大小自小二大的顺序连接。
3. 全部的中间节点元素都同时存在于子节点，在子节点中是最大（或最小）元素。

【    8 15    】
           /                   \
          /                     \
      【2 5 8】               【11 15】
     /    |     \              /      \ 
    /     |      \            /        \ 
   /      |       \          /          \
【1 2】->【3 5】->【6 8】->【9 11】--->【13 15】

在上面棵B+树中，根节点元素8是子节点【2 5 8】的最大元素，也是叶子节点【6 8】的最大元素
根节点元素15也是子节点【11 15】的最大元素，也是叶子节点的【13 15】的最大元素

须要注意的是，根节点的最大元素（这里是15），也就等同于整个B+树的最大元素。之后不管插入删除多少元素，始终要保持最大元素的根节点当中。

至于叶子节点，因为父节点的元素出如今子节点，所以全部叶子节点包含了全量元素信息。
而且每个叶子节点都带有指向下一个节点的指针，造成了一个有序链表。

B+树还有一个特色，这个特色是在索引以外，确实是相当重要的特色，那就是【卫星数据】的位置。
所谓卫星数据，指的是索引元素所指向的数据记录，好比数据库中的某一行。在B-树中，不管中间节点仍是叶子节点都带有卫星数据。

而在B+树中，只有叶子节点带有卫星数据，其他中间节点仅仅是索引，没有任何数据关联。
须要补充的是，在数据库的汇集索引（Clustered Index）中，叶子节点直接包含卫星数据。在非汇集索引（NonClustered Index）中，叶子节点带有指向卫星数据的指针。
B+树的好处主要体如今查询性能上：

• 在单元素查询的时候，B+树会自顶向下逐层查找节点，最终找到匹配的叶子节点。 这跟B-树不同的两点是，首先，B+树的中间节点没有卫星数据，因此一样大小的磁盘页能够容纳更多的节点元素。这意味，数据量相同的状况下，B+树的结果比B-树更加”矮胖“，所以查询时IO次数也更少。第二，B+树的查询必须最终查找到叶子节点，而B-树只要找到匹配元素便可，不管匹配元素处于中间节点仍是在叶子节点，所以，B-树是查找性能并不稳定（最好状况是只查根节点，最坏状况是查到叶子节点）。而B+树的每一次查找都是稳定的。
• 在范围查询的时候，B-树只能依靠繁琐的中序遍历。而B+树，很简单，只须要在链表上作遍历便可。

综合起来，B+树相比B-树的优点有三个：

1. IO次数更少；
2. 查询性能稳定；
3. 范围查询简便。

Mysql的阶树计算

　咱们能够来算一笔帐，以InnoDB存储引擎中默认每一个页的大小为16KB来计算，假设以int型的ID做为索引关键字，那么 一个int占用4byte，由上图能够知道还有其余的除主键之外的数据，姑且页当成4byte，那么这里就是8byte，那么16KB=161024byte，那么咱们在这种场景下，能够定义这个B-Tree的阶树为 （161024）/8=2048.那么这个树将会有2048-1路，也就是原来平衡二叉树(两路)的1024倍左右，从而大大提升了查找效率与下降IO读写次数。

参考：https://www.cnblogs.com/wuzhe...

Mysql Innodb数据页

其实mysql数据页结构不是单纯16KB都给数据用，请参考https://www.cnblogs.com/bdsir...

看来不管是这里的页，仍是操做系统内存的页page的概念，都是相似c语言的structure结构体的概念。

B+树索引的分裂优化

在4阶的B+树中(为了图好看直观，*表明是页面的可用空间)

【1 3 * *】
     /     \
    /       \
   /         \
【1 2 * *】->【3 4 5 6】

插入记录7时，因为叶节点的页面（下文简称叶页面）中只能存放4条记录，插入记录7时，会致使叶页面分裂，产生一个新的叶页面。

【1 3 5 *】
         /     |       \
        /      |        \
       /       |         \
      /        |          \
【1 2 * *】->【3 4 * *】->【5 6 7 *】

传统B+树页面裂变操做及分析：

• 按照原页面中50%的数据量进行分裂，针对当前这个分裂操做，3,4记录保留在原有页面，5,6记录移动到新的页面。最后将新记录7插入到新的页面中；

• 50%分裂策略的优点：

  • 分裂以后，亮哥页面的空间利用率是同样的；若是新的插入是随机在两个页面中挑选进行，那么下一个分裂的操做就会更晚触发。

• 50%分裂策略的劣势：

  • 空间利用率不高：按照传统50%的页面分裂策略，索引页面的空间利用率在50%左右；
  • 分裂频率较大：针对如上所示的递增插入（递减插入），每新插入两条记录，就会致使最后的叶页面在此发送分裂。

因为传统50%分裂的策略有不足之处。所以，针对B+树索引的递增/递减插入进行了优化（目前全部的关系型数据库，包括Oracle/InnoDB/PostgreSQL）。通过优化，上述B+树索引，在记录6插入完毕，记录7插入引发分裂以后，新的B+树结构以下：

【1 3 5 *】
         /     |       \
        /      |        \
       /       |         \
      /        |          \
【1 2 * *】->【3 4 5 6】->【7 * * *】

对比上下两个插入记录7以后，B+树索引的结构图，能够发现两者有不少不一样之处：

• 新的分裂策略，在插入7时，不移动原有页面的任何记录，只是将新插入的记录7写到新的页面中。
• 原有页面的利用率，仍旧是100%；

• 优化分裂策略的优点：

  • 索引分裂的代价小：不须要移动记录；
  • 索引分裂的几率下降：若是接下来的插入，仍旧是递增插入，那么须要插入4条记录，才能再次引发页面的分裂。50%分裂策略，分裂的概念下降了一半。
  • 索引页面的空间利用率提升：新的分裂策略，可以保证分裂前的页面，仍旧保持100%的利用率，提升索引的空间利用率。

• 优化分裂策略的优点：

  • 若是新的插入，再也不知足递增插入的条件，而是插入到原有页面，那么就会致使原有页面在此分裂，增长分裂的几率。

所以，此分裂的优化策略，仅仅是针对递增递减插入有效，针对随机插入，就是去了优化的意义，反而带来更高的分裂几率。 在InnoDB的实现中，为每一个索引页面维护了一个上次插入的位置，以及上次的插入是递增/递减的标识。根据这些信息，InnoDB可以判断出新插入的页面中的记录，是否仍旧知足递增/递减的约束，若知足约束，则采用优化后的分裂策略；若不知足越苏，则退回到50%的分类策略。这里提下，递增和递减，指的是趋势，因此Snowflake算法生成的序列是知足递增的约束。