B+树的学习

        在详细学习数据库的时候发现很多索引都是使用了B+树结构。那么B+树是什么呢，为何大部分的索引都采用B+的结构呢。

        先来看一下树的演化:

1. 树：非线性结构，每个节点有唯一的一个父结点和多个子结点（子树），为一对多的关系。
2. 二叉树：每个结点最多有两颗子树，并且子树有左右之分，不能颠倒。
3. 满二叉树：每一层的结点个数都达到了当层能达到的最大结点数。
4. 完全二叉树：除了最下面一层之外，其余层的结点个数都达到了当层能达到的最大结点数，且最下面一层只从左至右连续存在若干结点，而这些连续结点右边的结点全部不存在。
5. 二叉查找树(BST)是一种特殊的二叉树，又称为二叉排序树、二叉搜索树。二叉査找树的递归定义如下：  ①要么二叉査找树是一棵空树。②要么二叉查找树由根结点、左子树、右子树组成，其中左子树和右子树都是二叉查找树，且左子树上所有结点的数据域均小于或等于根结点的数据域，右子树上所有结点的数据域均大于根结点的数据域。
6. 平衡二叉树(AVL树)，是一种特殊的二叉排序树，其左右子树都平衡二叉树，且左右子树高度之差不大超过1。
7. B树属于多叉树，又名平衡多路查找树，查找路径有多个，一个树节点中包含多条数据，并包含多个指针域。B-树就是B树（别讲什么B减树，‘-’是分隔符）。
8. B+树，也是一种平衡多路查找树，是在B树的基础上发展而来的。

原文链接：https://blog.csdn.net/qq_42410605/article/details/122517769

为什么 MySQL 采用 B+ 树作为索引？

先看什么是索引？

MySQL官方对索引的定义为：索引（index）是帮助MySQL高效获取数据的数据结构。

 索引的目的在提高查询效率。如果没有索引就需要a-z进行全表扫描。一般来说索引本身也很大，不可能全部储存在内存中，因此索引往往以索引文件的形式存储在磁盘上。

 索引的优缺点：

优点：

• 提高数据检索的效率，降低数据库的IO成本（不需要全表扫描）
• 通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗    

缺点

• 实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引列也是要占空间的
• 虽然索引大大的提高了查询速度，同时却会降低更新表的速度，因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件
• 每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息
• 索引只是提高效率的一个因素，如果MySQL有大量数据的表，就需要花时间研究建立最优秀的索引，或优化查询语句，索引都是不停的根据业务场景不停修改调整的

怎样的索引的数据结构是好的？

MySQL 的数据是持久化的，意味着数据（索引+记录）是保存到磁盘上的，因为这样即使设备断电了，数据也不会丢失。

磁盘是一个慢的离谱的存储设备，有多离谱呢？

人家内存的访问速度是纳秒级别的，而磁盘访问的速度是毫秒级别的，也就是说读取同样大小的数据，磁盘中读取的速度比从内存中读取的速度要慢上万倍，甚至几十万倍。

磁盘读写的最小单位是扇区，扇区的大小只有 512B 大小，操作系统一次会读写多个扇区，所以操作系统的最小读写单位是块（Block）。Linux 中的块大小为 4KB，也就是一次磁盘 I/O 操作会直接读写 8 个扇区。

由于数据库的索引是保存到磁盘上的，因此当我们通过索引查找某行数据的时候，就需要先从磁盘读取索引到内存，再通过索引从磁盘中找到某行数据，然后读入到内存，也就是说查询过程中会发生多次磁盘 I/O，而磁盘 I/O 次数越多，所消耗的时间也就越大。

所以，我们希望索引的数据结构能在尽可能少的磁盘的 I/O 操作中完成查询工作，因为磁盘 I/O 操作越少，所消耗的时间也就越小。

另外，MySQL 是支持范围查找的，所以索引的数据结构不仅要能高效地查询某一个记录，而且也要能高效地执行范围查找。

所以，要设计一个适合 MySQL 索引的数据结构，至少满足以下要求：

1. 能在尽可能少的磁盘的 I/O 操作中完成查询工作；
2. 要能高效地查询某一个记录，也要能高效地执行范围查找；

为什么不使用二叉查找树？

二叉查找树可能出现“一条龙”的景象，把二叉树特殊化为一个链表，相当于全表扫描，查找元素发挥不了二叉排序树的优势，只能按照链表的形式查找，高度太高了，查找效率不稳定。

为什么不使用平衡二叉树？

平衡二叉树解决了二叉树高度太高，查找效率不稳定的问题。但是，平衡二叉树的每个节点只存储一个键值和数据，如果数据非常的多（大多数情况下数据是海量的），二叉树的结点将会非常多，高度也会及其高，查找效率降低。

为什么不使用B树？

B树相对于平衡二叉树，优势在于每个节点存储了更多的键值(key)和数据(data)，并且每个节点拥有更多的子结点，高度就会降低，B树在提高了IO性能的同时并没有解决元素遍历效率低下的问题，在找数据时需要遍历整个B树，为解决这个问题引出了B+树。

什么是B+树？

1. B+树非叶子节点上是不存储数据的，仅存储键值，而B树节点中不仅存储键值，也会存储数据。数据库中页的大小是固定的，innodb中页的默认大小是16KB。如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的IO次数会再次减少，数据查询的效率也会更快。另外，B+树的阶数是等于键值的数量的，如果我们的B+树一个节点可以存储1000个键值，那么3层B+树可以存储1000×1000×1000=10亿个数据。一般根节点是常驻内存的，所以一般我们查找10亿数据，只需要2次磁盘IO。 

2. 因为B+树索引的所有数据均存储在叶子节点，并用链表链接成一个线性表【在数据库设计中B+树中各个页之间是通过双向链表连接的，叶子节点中的数据是通过单向链表连接的】。而且数据是按照顺序排列的。那么B+树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。而B树因为数据分散在各个节点，要实现这一点是很不容易的。  

为什么MySQL选择B+树做索引

1、B+树的磁盘读写代价更低：B+树的内部节点并没有指向关键字具体信息的指针，因此其内部节点相对B树更小，如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存的需要查找的关键字也就越多，相对IO读写次数就降低了。

2、B+树的查询效率更加稳定：由于非叶子结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

3、B+树更便于遍历：由于B+树的数据都存储在叶子结点中，非叶子结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。

4、B+树更适合基于范围的查询：B树在提高了IO性能的同时并没有解决元素遍历的我效率低下的问题，正是为了解决这个问题，B+树应用而生。B+树只需要去遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作或者说效率太低。

【数据库】B树、B+树、索引_皮皮要HAPPY的博客-CSDN博客_数据库索引b树和b+树

MySQL中存储索引用到的数据结构是B+树，B+树的查询时间跟树的高度有关，是log(n)，如果用hash存储，那么查询时间是O(1)。既然hash比B+树更快，为什么mysql用B+树来存储索引呢？
从内存角度上说，数据库中的索引一般时在磁盘上，数据量大的情况可能无法一次性装入内存，B+树的设计可以允许数据分批加载。
从业务场景上说，如果只选择一个数据那确实是hash更快，但是数据库中经常会选中多条这时候由于B+树索引有序，并且又有链表相连，它的查询效率比hash就快很多了，hash还需要解决冲突。

• Hash索引和B+树区别是什么？你在设计索引是怎么抉择的？
• B+树可以进行范围查询，Hash索引不能。
• B+树支持联合索引的最左侧原则，Hash索引不支持。
• B+树支持order by排序，Hash索引不支持。
• Hash索引在等值查询上比B+树效率更高。
• B+树使用like进行模糊查询的时候，like后面（比如%开头）的话可以起到优化的作用，Hash索引根本无法进行模糊查询。

问题2：既然增加树的路数可以降低树的高度，那么无限增加树的路数是不是可以有最优的查找效率？

答：这样会形成一个有序数组，文件系统和数据库的索引都是存在硬盘上的，并且如果数据量大的话，不一定能一次性加载到内存中。有序数组没法一次性加载进内存，这时候B+树的多路存储威力就出来了，可以每次加载B+树的一个结点，然后一步步往下找。