在平时工作中，接触到的数据库最多的就是Mysql数据库了，mysql数据库它的开源免费特性以及支持百万级存储性能，受到许多中小公司的青睐，甚至是阿里这样的巨头都在使用，基本大部分开发人员第一次接触的也都是基于Mysql作为底层数据的存储，来入门web软件开发，CRUD用的很多，复杂的多表查询，各种内外连接，以及子查询和group by 等操作，但是只知其一不知其二，本着知其然，也要知其所以然的态度，本篇文章来记录研究下mysql内部理论和实现机制。
无数据库实现快速查询
思考一个问题，当早期没有数据库的时候，如何快速的查询数据呢，这里如果让你来设计实现一个系统，如何能够快速的检索到保存的数据呢。生活中，当我们思索解决问题的方式的时候，通常会寻找出一个熟悉的事物去套,这里我们举个生活中的例子，比如一个我们从一本书中要快速找到想看的章节，我们是怎么做的呢？我们的做法是首先翻到目录页，然后找到目录页内容，最后找到感兴趣的想看的后，根据目录页面的页码，就可以很快找到了。这里的目录其实就是类比数据库的索引，所以我们高效快速找到想要的数据。这里就分析得出一个结论，索引能够快速的提高数据的查询。
如果不用数据库来查询，那么可以通过将数据文件写入本地或者网络上其他机器，文件类型可以是自定义格式，或者用excel 表格，数据库也是解决数据存储和计算的服务器，这样如何解决查询的问题，基本就需要根据文件格式来定义，这样存在一个问题就是，查询方式不能够统一。这里我们如果用excel表格来存储数据，那么我们将第一行做为表格头，这里表格头是作为数据列字段，那么查询的时候，比如我们要查询下图中的学号为3的学生，那么必须定位到C列才行，然后将该列处了C1以外的数据全部检索出来，然后通过程序将数据读取到内存中，然后再找到其中的学好为3的王五。这里就涉及到全文检索，这里举例中只有三条数据，并且每条记录字段只有3个，分别是姓名，年龄，学号，如果是更多呢，一亿条呢？那么将对我们的内存是个极大的挑战，所以这里我们需要建立索引，通过索引来快速定位到要查询的数据，而不是轮询。
这里我们就需要根据学号来建立一个索引，把学号作为key,其他的字段作为value，来存储，当我们下次再找到学号为3的时候，可以直接快速查找到学号为3的王五。
那么如何去存储呢？一个良好的设计的数据结构可以很快的解决遇到的难题。学过的数据结构有，数组，链表，有Map结构等，分别对应集合，线性结构，树形结构，图形结构。
树形结构：数据结构中的元素存在一对多的相互关系
图形结构：数据结构中的元素存在多对多的相互关系
数据结构是计算机存储、组织数据的方式。数据结构是指相互之间存在一种或多种特定关系的数据元素的集合。通常情况下，精心选择的数据结构可以带来更高的运行或者存储效率。数据结构往往同高效的检索算法和索引技术有关。
重点关注的是树形结构，在从一堆数据中查找指定的数据时，我们常用的数据结构是哈希表和二叉查找树，表本质上就是一堆数据的集合，所以MySQL数据库用了哈希表和B+树来实现索引
二叉查找树
二叉查找树是带有特殊属性的二叉树，需要满足以下属性
非叶子节点最多拥有两个子节点
非叶子节值大于左边子节点、小于右边子节点（左小右大）
没有值相等重复的节点;
首先，让我们看下这个图
从图中可以看出，user表有id 和name 两个字段，右边的是二叉树索引的构建图，最上层是根节点，根节点上10是存储的键值，这里id就是key值，那么这个树的构成因为二叉树的性质，"左小又大",那么id为7，name是ls的用户就应该放在10的左边，id是13的节点，name为ww的用户就在根节点的又边。
图中的圆为二叉查找树的节点，节点中存储了键（key）和数据（data）。键对应 user 表中的 id，数据对应 user 表中的行数据。
二叉查找树的特点就是任何节点的左子节点的键值都小于当前节点的键值，右子节点的键值都大于当前节点的键值。顶端的节点我们称为根节点，没有子节点的节点我们称之为叶节点。
如果我们需要查找 id=12 的用户信息，利用我们创建的二叉查找树索引，查找流程如下：
将根节点作为当前节点，把 12 与当前节点的键值 10 比较，12 大于 10，接下来我们把当前节点>的右子节点作为当前节点。
继续把 12 和当前节点的键值 13 比较，发现 12 小于 13，把当前节点的左子节点作为当前节点。
-
把 12 和当前节点的键值 12 对比，12 等于 12，满足条件，我们从当前节点中取出 data，即 id=12，name=xm。
利用二叉查找树我们只需要 3 次即可找到匹配的数据。如果在表中一条条的查找的话，我们需要 6 次才能找到。
平衡二叉树
上面我们讲解了二叉树查找的过程，利用二叉查找树可以快速的查询到数据，但是假如有这样一条特例，如下图所示：
这个时候，我们看到二叉查找树变成了一个链表结构，如果我们要查找到id值为17的节点，那么我们需要查找7次，就相当于全表扫描。导致这个现象的原因就是因为这个二叉树不是传统的二叉树，从图中看出来就怪异，也就是变的不平衡了，这个层级有7层，从而导致查找的效率不稳定。为了解决这个问题，我们需要一个平衡的二叉树。平衡二叉树又叫AVl树，在满足二叉查找树特性的基础上，要求每个节点的左右子树的高度差不能超过 1。
由平衡二叉树的构造我们可以发现第一张图中的二叉树其实就是一棵平衡二叉树。
平衡二叉树保证了树的构造是平衡的，当我们插入或删除数据导致不满足平衡二叉树不平衡时，平衡二叉树会进行调整树上的节点来保持平衡。具体的调整方式这里就不介绍了。平衡二叉树相比于二叉查找树来说，查找效率更稳定，总体的查找速度也更快。
B 树
当我们平时在使用内存的时候，由于内存中的存储的数据在断电的时候，容易丢失，所以我们基本都会将数据存储在磁盘这种外围设备上，比如将这里的user表中的数据和索引存储。但是和内存相比，从磁盘上读取数据的速度就要相对慢很多，所以我们应当尽量减少从磁盘读取的次数，并且我们平时从磁盘中读取数据，都是按照磁盘块来读取的，并不是一条一条来读的。如果我们有大量的数据已经存储在磁盘上，那一次磁盘读取操作就会读取更多数据，从而我们查找数据的时间也会大幅度降低。如果我们用平衡二叉树来查找数据，平衡二叉树可是每个节点只存储一个键值和数据的，那么我们每次读取一个节点的数据都要从磁盘块中获取一次，如果有大量的数据要读取呢，岂不是每次读取一个节点数据就得去磁盘块中找一次，可以想象到二叉树的节点将会非常多，高度也会极其高，我们查找数据时也会进行很多次磁盘 IO，我们查找数据的效率将会极低。
为了解决平衡二叉树的这个弊端，我们应该寻找一种单个节点可以存储多个键值和数据的平衡树。也就是我们接下来要说的 B 树。
B 树（Balance Tree）即为平衡树的意思，下图即是一棵 B 树
图中的 p 节点为指向子节点的指针，二叉查找树和平衡二叉树其实也有，因为图的美观性，被省略了。
图中的每个节点称为页，页就是我们上面说的磁盘块，在 MySQL 中数据读取的基本单位都是页，所以我们这里叫做页更符合 MySQL 中索引的底层数据结构。
从上图可以看出，B 树相对于平衡二叉树，每个节点存储了更多的键值（key）和数据（data），并且每个节点拥有更多的子节点，子节点的个数一般称为阶，上述图中的 B 树为 3 阶 B 树，高度也会很低。
基于这个特性，B 树查找数据读取磁盘的次数将会很少，数据的查找效率也会比平衡二叉树高很多。
假如我们要查找 id=28 的用户信息，那么我们在上图 B 树中查找的流程如下：
- 先找到根节点也就是页 1，判断 28 在键值 17 和 35 之间，那么我们根据页 1 中的指针 p2 找到页 3。
- 将 28 和页 3 中的键值相比较，28 在 26 和 30 之间，我们根据页 3 中的指针 p2 找到页 8。
- 将 28 和页 8 中的键值相比较，发现有匹配的键值 28，键值 28 对应的用户信息为（28，bv）。
B+ 树
B+ 树是对 B 树的进一步优化。让我们先来看下 B+ 树的结构图：
根据上图我们来看下 B+ 树和 B 树有什么不同：
B+ 树非叶子节点上是不存储数据的，仅存储键值，而 B 树节点中不仅存储键值，也会存储数据。 之所以这么做是因为在数据库中页的大小是固定的，InnoDB 中页的默认大小是 16KB。如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的 IO 次数又会再次减少，数据查询的效率也会更快。另外，B+ 树的阶数是等于键值的数量的，如果我们的 B+ 树一个节点可以存储 1000 个键值，那么 3 层 B+ 树可以存储 1000×1000×1000=10 亿个数据。一般根节点是常驻内存的，所以一般我们查找 10 亿数据，只需要 2 次磁盘 IO。
因为 B+ 树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的。那么 B+ 树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。而 B 树因为数据分散在各个节点，要实现这一点是很不容易的。有心的读者可能还发现上图 B+ 树中各个页之间是通过双向链表连接的，叶子节点中的数据是通过单向链表连接的。其实上面的 B 树我们也可以对各个节点加上链表。这些不是它们之前的区别，是因为在 MySQL 的 InnoDB 存储引擎中，索引就是这样存储的。也就是说上图中的 B+ 树索引就是 InnoDB 中 B+ 树索引真正的实现方式，准确的说应该是聚集索引（聚集索引和非聚集索引下面会讲到）。通过上图可以看到，在 InnoDB 中，我们通过数据页之间通过双向链表连接以及叶子节点中数据之间通过单向链表连接的方式可以找到表中所有的数据。MyISAM 中的 B+ 树索引实现与 InnoDB 中的略有不同。在 MyISAM 中，B+ 树索引的叶子节点并不存储数据，而是存储数据的文件地址。
聚集索引 VS 非聚集索引
在上节介绍 B+ 树索引的时候，我们提到了图中的索引其实是聚集索引的实现方式。
那什么是聚集索引呢？在 MySQL 中，B+ 树索引按照存储方式的不同分为聚集索引和非聚集索引。
这里我们着重介绍 InnoDB 中的聚集索引和非聚集索引：
聚集索引（聚簇索引）：以 InnoDB 作为存储引擎的表，表中的数据都会有一个主键，即使你不创建主键，系统也会帮你创建一个隐式的主键。这是因为 InnoDB 是把数据存放在 B+ 树中的，而 B+ 树的键值就是主键，在 B+ 树的叶子节点中，存储了表中所有的数据。这种以主键作为 B+ 树索引的键值而构建的 B+ 树索引，我们称之为聚集索引。
非聚集索引（非聚簇索引）：以主键以外的列值作为键值构建的 B+ 树索引，我们称之为非聚集索引。非聚集索引与聚集索引的区别在于非聚集索引的叶子节点不存储表中的数据，而是存储该列对应的主键，想要查找数据我们还需要根据主键再去聚集索引中进行查找，这个再根据聚集索引查找数据的过程，我们称为回表。明白了聚集索引和非聚集索引的定义，我们应该明白这样一句话：数据即索引，索引即数据。
利用聚集索引和非聚集索引查找数据
前面我们讲解 B+ 树索引的时候并没有去说怎么在 B+ 树中进行数据的查找，主要就是因为还没有引出聚集索引和非聚集索引的概念。
下面我们通过讲解如何通过聚集索引以及非聚集索引查找数据表中数据的方式介绍一下 B+ 树索引查找数据方法。
还是这张 B+ 树索引图，现在我们应该知道这就是聚集索引，表中的数据存储在其中。
现在假设我们要查找 id>=18 并且 id<40 的用户数据。对应的 sql 语句为：
select * from user where id>=18 and id <40
其中 id 为主键，具体的查找过程如下：
一般根节点都是常驻内存的，也就是说页 1 已经在内存中了，此时不需要到磁盘中读取数据，直接从内存中读取即可。从内存中读取到页 1，要查找这个 id>=18 and id <40 或者范围值，我们首先需要找到 id=18 的键值。从页 1 中我们可以找到键值 18，此时我们需要根据指针 p2，定位到页 3。
要从页 3 中查找数据，我们就需要拿着 p2 指针去磁盘中进行读取页 3。从磁盘中读取页 3 后将页 3 放入内存中，然后进行查找，我们可以找到键值 18，然后再拿到页 3 中的指针 p1，定位到页 8。
同样的页 8 页不在内存中，我们需要再去磁盘中将页 8 读取到内存中。将页 8 读取到内存中后。因为页中的数据是链表进行连接的，而且键值是按照顺序存放的，此时可以根据二分查找法定位到键值 18。此时因为已经到数据页了，此时我们已经找到一条满足条件的数据了，就是键值 18 对应的数据。因为是范围查找，而且此时所有的数据又都存在叶子节点，并且是有序排列的，那么我们就可以对页 8 中的键值依次进行遍历查找并匹配满足条件的数据。我们可以一直找到键值为 22 的数据，然后页 8 中就没有数据了，此时我们需要拿着页 8 中的 p 指针去读取页 9 中的数据。
因为页 9 不在内存中，就又会加载页 9 到内存中，并通过和页 8 中一样的方式进行数据的查找，直到将页 12 加载到内存中，发现 41 大于 40，此时不满足条件。那么查找到此终止。最终我们找到满足条件的所有数据，总共 12 条记录：(18,kl), (19,kl), (22,hj), (24,io), (25,vg) , (29,jk), (31,jk) , (33,rt) , (34,ty) , (35,yu) , (37,rt) , (39,rt) 。
利用非聚集索引查找数据
非聚集索引中x-y这里，在叶子节点中，不再存储所有的数据了，存储的是键值和主键。对于叶子节点中的 x-y，比如 1-1。左边的 1 表示的是索引的键值，右边的 1 表示的是主键值。
select * from user where luckNum=33
查找的流程跟聚集索引一样，这里就不详细介绍了。我们最终会找到主键值 47，找到主键后我们需要再到聚集索引中查找具体对应的数据信息，此时又回到了聚集索引的查找流程。看下具体的查找流程图：
总结
本篇文章从无数据库开始讲起，一直引伸出二叉查找树，详细说明了为什么 MySQL 用 B+ 树作为数据的索引，以及在 InnoDB 中数据库如何通过 B+ 树索引来存储数据以及查找数据。我们一定要记住这句话：数据即索引，索引即数据。
原文部分参考地址：http://www.liuzk.com/410.html