共计 1238 个字符，预计需要花费 4 分钟才能阅读完成。
一个工作 8 年的粉丝私信了我一个问题。
他说这个问题是去阿里面试的时候被问到的，本人查了很多材料也没搞明确，心愿我帮他解答。
问题是：“Mysql 为什么应用 B +Tree 作为索引构造”
对于这个问题，看看普通人和高手的答复。
普通人：
B+ 数它的特色就是绝对 B 数来说他的这个非叶子节点不存数据，所有的数据都存在叶子节点
绝对于 B 数来说他的查问次数 IO 次数会更稳。
高手：
对于这个问题，我从几个方面来答复。
首先，惯例的数据库存储引擎，个别都是采纳 B 树或者 B + 树来实现索引的存储。
因为 B 树是一种多路均衡树，用这种存储构造来存储大量数据，它的整个高度会相比二叉树来说，会矮很多。
而对于数据库来说，所有的数据必然都是存储在磁盘上的，而磁盘 IO 的效率实际上是很低的，特地是在随机磁盘 IO 的状况下效率更低。
所以树的高度可能决定磁盘 IO 的次数，磁盘 IO 次数越少，对于性能的晋升就越大，这也是为什么采纳 B 树作为索引存储构造的起因。
然而在 Mysql 的 InnoDB 存储引擎外面，它用了一种加强的 B 树结构，也就是 B + 树来作为索引和数据的存储构造。
相比拟于 B 树结构，B+ 树做了几个方面的优化。
- B+ 树的所有数据都存储在叶子节点，非叶子节点只存储索引。
- 叶子节点中的数据应用双向链表的形式进行关联。
应用 B + 树来实现索引的起因，我认为有几个方面。
- B+ 树非叶子节点不存储数据，所以每一层可能存储的索引数量会减少，意味着 B + 树在层高雷同的状况下存储的数据量要比 B 树要多，使得磁盘 IO 次数更少。
- 在 Mysql 外面，范畴查问是一个比拟罕用的操作，而 B + 树的所有存储在叶子节点的数据应用了双向链表来关联，所以在查问的时候只需查两个节点进行遍历就行，而 B 树须要获取所有节点，所以 B + 树在范畴查问上效率更高。
- 在数据检索方面，因为所有的数据都存储在叶子节点，所以 B + 树的 IO 次数会更加稳固一些。
- 因为叶子节点存储所有数据，所以 B + 树的全局扫描能力更强一些，因为它只须要扫描叶子节点。然而 B 树须要遍历整个树。
另外，基于 B + 树这样一种构造，如果采纳自增的整型数据作为主键，还能更好的防止减少数据的时候，带来叶子节点决裂导致的大量运算的问题。
总的来说，我认为技术计划的选型，更多的是去解决以后场景下的特定问题，并不一定是说 B + 树就是最好的抉择，就像 MongoDB 外面采纳 B 树结构，实质上来说，其实是关系型数据库和非关系型数据库的差别。
以上就是我对这个问题的了解。
总结
对于“为什么要抉择 xx 技术”的问题，其实很好答复。
只有你对这个技术自身的个性足够理解，那么天然就晓得为什么要这么设计。
就像，咱们在业务开发中，晓得什么时候应用 List，什么时候应用 Map，情理是一样的。
如果有任何面试问题、职业倒退问题、学习问题，都能够私信我。
版权申明：本博客所有文章除特地申明外，均采纳 CC BY-NC-SA 4.0 许可协定。转载请注明来自
Mic 带你学架构！
如果本篇文章对您有帮忙，还请帮忙点个关注和赞，您的保持是我一直创作的能源。欢送关注同名微信公众号获取更多技术干货！