为什么 MySQL 选择 B＋树作为存储引擎索引结构

在数据库或者存储的世界里，存储引擎的角色一直处于核心位置。往简单了说，存储引擎主要负责数据如何读写。往复杂了说，怎么快速、高效的完成数据的读写，一直是存储引擎要解决的关键问题。在绝大部分介绍、讲解存储引擎的书籍或者文章里，大家都默认了读多写少的磁盘存储引擎采用的就是b+树，而极少有人来剖析选择b+树作为索引结构的背后，到底有着怎样的思考和权衡？为了解答上述问题，本文尝试从一个新的视角和大家讨论：
在处理读多写少的场景下，为什么基于磁盘的存储引擎会选择用 B+ 树来作为索引结构？
希望在看完本文后，读者能对该问题有一个全新的认识和属于自己的答案。限于个人能力有限，有表述、理解不正当之处希望批评指正。
本文的内容主要以问答方式展开，层层递进分析、解决问题，本文涉及内容会围绕下面三个问题展开。在开始阅读本文内容前，大家不妨先尝试自己回答下面三个问题！

本文插图
为了减少读者的疑惑，在开始本文的正式内容之前，先和读者做一些简要的关键名词的解释和说明：
1.存储引擎：
存储引擎是一个很广的范畴，有处理读多写少的基于页结构的 B+ 树存储引擎，也有后起之秀基于日志结构(LSM Tree)的存储引擎。在本文中提到的存储引擎，如没有特殊说明，都指的是
针对处理读多写少场景的基于磁盘的 B+ 树存储引擎
，这类存储引擎在关系型数据库中出现的频率较高，经典代表就是 MySQL 中的 InnoDB ，此外 Golang 编写的 BoltDB 也属于本文讨论的范畴。
2.扩展内容：
文中标识为扩展内容的章节，对于基础相对较好的读者这些内容可以选择性阅读，不读也不会造成本文核心内容理解困难；对于基础相对一般的小伙伴，可以选择性的进行阅读。
下面我们先尝试回答前两个问题，因为前两个问题可以算作是一大类问题。第一个问题主要在于数据结构的选型。第二个问题主要在于因果关系的区分。

本文插图
1.背景
这个问题的答案，我们从哪里开始说起呢？想之又想，只有搞清楚了整体的一个背景，我们才能知道当时的工程师面临的怎样的一个问题。近而，我们才能尝试从根上解释这个问题。从整体的大的环境来看，他们要解决的问题主要面临的以下四个主要特点：
1. 处理读多写少的场景
2. 关系型数据库按照行组织
3. 存储千万级量级数据