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算法生成的序列是满足递增的约束。