MySQL的索引为什么是B+树而不是B树或红黑树

MySQL的索引为什么是B+树，而不是B树或者红黑树

一、为什么不是B树？

1、B+树的中间节点没有卫星数据的。所以同样大小的磁盘页可以容纳更多的节点元素。（这就意味着B+会更加矮胖，查询的IO次数会更少）

B树的卫星数据

B+树的卫星数据

2、B树查找性能是不稳定的（如果要查找的数据分别在根节点和叶子节点，他们的性能就会不同）。但B+树的每一次都是稳定的，因为所有的数据都集中在叶子节点上。

B+树相对于B树的优势：

1.单一节点存储更多的元素，使得查询的IO次数更少。

2.所有查询都要查找到叶子节点，查询性能稳定。

3.所有叶子节点形成有序链表，便于范围查询。

二、为什么不是红黑树？

AVL 树和红黑树这些二叉树结构的数据结构可以达到最高的查询效率这是毋庸置疑的。

既然如此，那么数据库索引为什么不用 AVL 树或者红黑树呢？

AVL 数和红黑树基本都是存储在内存中才会使用的数据结构，那磁盘中会有什么不同呢？

这就要牵扯到磁盘的存储原理了

操作系统读写磁盘的基本单位是扇区，而文件系统的基本单位是簇(Cluster)。

也就是说，磁盘读写有一个最少内容的限制，即使我们只需要这个簇上的一个字节的内容，我们也要含着泪把一整个簇上的内容读完。

那么，现在问题就来了

一个父节点只有 2 个子节点，并不能填满一个簇上的所有内容啊？那多余的内容岂不是要浪费了？我们怎么才能把浪费的这部分内容利用起来呢？哈哈，答案就是 B+ 树。

由于 B+ 树分支比二叉树更多，所以相同数量的内容，B+ 树的深度更浅，深度代表什么？代表磁盘 io 次数啊！数据库设计的时候 B+ 树有多少个分支都是按照磁盘一个簇上最多能放多少节点设计的啊！

所以，涉及到磁盘上查询的数据结构，一般都用 B+ 树啦。

多少节点设计的啊！

所以，涉及到磁盘上查询的数据结构，一般都用 B+ 树啦。