Java架构—MySQL的InnoDB索引原理详解

本篇介绍下Mysql的InnoDB索引相关知识，从各类树到索引原理到存储的细节。

InnoDB是Mysql的默认存储引擎(Mysql5.5.5以前是MyISAM，文档)。本着高效学习的目的，本篇以介绍InnoDB为主，少许涉及MyISAM做为对比。

这篇文章是我在学习过程当中总结完成的，内容主要来自书本和博客(参考文献会给出)，过程当中加入了一些本身的理解，描述不许确的地方烦请指出。

1 各类树形结构

原本不打算从二叉搜索树开始，由于网上已经有太多相关文章，可是考虑到清晰的图示对理解问题有很大帮助，也为了保证文章完整性，最后仍是加上了这部分。

先看看几种树形结构：

1 搜索二叉树：每一个节点有两个子节点，数据量的增大必然致使高度的快速增长，显然这个不适合做为大量数据存储的基础结构。

2 B树：一棵m阶B树是一棵平衡的m路搜索树。最重要的性质是每一个非根节点所包含的关键字个数 j 知足：┌m/2┐ - 1 <= j <= m - 1；一个节点的子节点数量会比关键字个数多1，这样关键字就变成了子节点的分割标志。通常会在图示中把关键字画到子节点中间，很是形象，也容易和后面的B+树区分。因为数据同时存在于叶子节点和非叶子结点中，没法简单完成按顺序遍历B树中的关键字，必须用中序遍历的方法。

3 B+树：一棵m阶B树是一棵平衡的m路搜索树。最重要的性质是每一个非根节点所包含的关键字个数 j 知足：┌m/2┐ - 1 <= j <= m；子树的个数最多能够与关键字同样多。非叶节点存储的是子树里最小的关键字。同时数据节点只存在于叶子节点中，且叶子节点间增长了横向的指针，这样顺序遍历全部数据将变得很是容易。

4 B*树：一棵m阶B树是一棵平衡的m路搜索树。最重要的两个性质是1每一个非根节点所包含的关键字个数 j 知足：┌m2/3┐ - 1 <= j <= m；2非叶节点间添加了横向指针。

B/B+/B*三种树有类似的操做，好比检索/插入/删除节点。这里只重点关注插入节点的状况，且只分析他们在当前节点已满状况下的插入操做，由于这个动做稍微复杂且能充分体现几种树的差别。与之对比的是检索节点比较容易实现，而删除节点只要完成与插入相反的过程便可（在实际应用中删除并非插入的彻底逆操做，每每只删除数据而保留下空间为后续使用）。

先看B树的分裂，下图的红色值即为每次新插入的节点。每当一个节点满后，就须要发生分裂（分裂是一个递归过程，参考下面7的插入致使了两层分裂），因为B树的非叶子节点一样保存了键值，因此已满节点分裂后的值将分布在三个地方：1原节点，2原节点的父节点，3原节点的新建兄弟节点（参考5，7的插入过程）。分裂有可能致使树的高度增长（参考3，7的插入过程），也可能不影响树的高度（参考5，6的插入过程）。

B+树的分裂：当一个结点满时，分配一个新的结点，并将原结点中1/2的数据复制到新结点，最后在父结点中增长新结点的指针；B+树的分裂只影响原结点和父结点，而不会影响兄弟结点，因此它不须要指向兄弟节点的指针。

B 树的分裂：当一个结点满时，若是它的下一个兄弟结点未满，那么将一部分数据移到兄弟结点中，再在原结点插入关键字，最后修改父结点中兄弟结点的关键字（由于兄弟结点的关键字范围改变了）。若是兄弟也满了，则在原结点与兄弟结点之间增长新结点，并各复制1/3的数据到新结点，最后在父结点增长新结点的指针。能够看到B树的分裂很是巧妙，由于B 树要保证分裂后的节点还要2/3满，若是采用B+树的方法，只是简单的将已满的节点一分为二，会致使每一个节点只有1/2满，这不知足B树的要求了。因此B 树采起的策略是在本节点满后，继续插入兄弟节点（这也是为何B树须要在非叶子节点加一个兄弟间的链表），直到把兄弟节点也塞满，而后拉上兄弟节点一块儿凑份子，本身和兄弟节点各出资1/3成立新节点，这样的结果是3个节点恰好是2/3满，达到B*树的要求，皆大欢喜。

B+树适合做为数据库的基础结构，彻底是由于计算机的内存-机械硬盘两层存储结构。内存能够完成快速的随机访问（随机访问即给出任意一个地址，要求返回这个地址存储的数据）可是容量较小。而硬盘的随机访问要通过机械动做（1磁头移动 2盘片转动），访问效率比内存低几个数量级，可是硬盘容量较大。典型的数据库容量大大超过可用内存大小，这就决定了在B+树中检索一条数据极可能要借助几回磁盘IO操做来完成。以下图所示：一般向下读取一个节点的动做可能会是一次磁盘IO操做，不过非叶节点一般会在初始阶段载入内存以加快访问速度。同时为提升在节点间横向遍历速度，真实数据库中可能会将图中蓝色的CPU计算/内存读取优化成二叉搜索树（InnoDB中的page directory机制）。

真实数据库中的B+树应该是很是扁平的，能够经过向表中顺序插入足够数据的方式来验证InnoDB中的B+树到底有多扁平。咱们经过以下图的CREATE语句创建一个只有简单字段的测试表，而后不断添加数据来填充这个表。经过下图的统计数据（来源见参考文献1）能够分析出几个直观的结论，这几个结论宏观的展示了数据库里B+树的尺度。

1 每一个叶子节点存储了468行数据，每一个非叶子节点存储了大约1200个键值，这是一棵平衡的1200路搜索树！

2 对于一个22.1G容量的表，也只须要高度为3的B+树就能存储了，这个容量大概能知足不少应用的须要了。若是把高度增大到4，则B+树的存储容量马上增大到25.9T之巨！

3 对于一个22.1G容量的表，B+树的高度是3，若是要把非叶节点所有加载到内存也只须要少于18.8M的内存（如何得出的这个结论？由于对于高度为2的树，1203个叶子节点也只须要18.8M空间，而22.1G从良表的高度是3，非叶节点1204个。同时咱们假设叶子节点的尺寸是大于非叶节点的，由于叶子节点存储了行数据而非叶节点只有键和少许数据。），只使用如此少的内存就能够保证只须要一次磁盘IO操做就检索出所需的数据，效率是很是之高的。

2 Mysql的存储引擎和索引

能够说数据库必须有索引，没有索引则检索过程变成了顺序查找，O(n)的时间复杂度几乎是不能忍受的。咱们很是容易想象出一个只有单关键字组成的表如何使用B+树进行索引，只要将关键字存储到树的节点便可。当数据库一条记录里包含多个字段时，一棵B+树就只能存储主键，若是检索的是非主键字段，则主键索引失去做用，又变成顺序查找了。这时应该在第二个要检索的列上创建第二套索引。 这个索引由独立的B+树来组织。有两种常见的方法能够解决多个B+树访问同一套表数据的问题，一种叫作聚簇索引（clustered index ），一种叫作非聚簇索引（secondary index）。这两个名字虽然都叫作索引，但这并非一种单独的索引类型，而是一种数据存储方式。对于聚簇索引存储来讲，行数据和主键B+树存储在一块儿，辅助键B+树只存储辅助键和主键，主键和非主键B+树几乎是两种类型的树。对于非聚簇索引存储来讲，主键B+树在叶子节点存储指向真正数据行的指针，而非主键。

InnoDB使用的是聚簇索引，将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用"where id = 14"这样的条件查找主键，则按照B+树的检索算法便可查找到对应的叶节点，以后得到行数据。若对Name列进行条件搜索，则须要两个步骤：第一步在辅助索引B+树中检索Name，到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操做，最终到达叶子节点便可获取整行数据。

MyISM使用的是非聚簇索引，非聚簇索引的两棵B+树看上去没什么不一样，节点的结构彻底一致只是存储的内容不一样而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来讲，这两个键没有任何差异。因为索引树是独立的，经过辅助键检索无需访问主键的索引树。

为了更形象说明这两种索引的区别，咱们假想一个表以下图存储了4行数据。其中Id做为主索引，Name做为辅助索引。图示清晰的显示了聚簇索引和非聚簇索引的差别。

咱们重点关注聚簇索引，看上去聚簇索引的效率明显要低于非聚簇索引，由于每次使用辅助索引检索都要通过两次B+树查找，这不是画蛇添足吗？聚簇索引的优点在哪？

1 因为行数据和叶子节点存储在一块儿，这样主键和行数据是一块儿被载入内存的，找到叶子节点就能够马上将行数据返回了，若是按照主键Id来组织数据，得到数据更快。

2 辅助索引使用主键做为"指针" 而不是使用地址值做为指针的好处是，减小了当出现行移动或者数据页分裂时辅助索引的维护工做，使用主键值看成指针会让辅助索引占用更多的空间，换来的好处是InnoDB在移动行时无须更新辅助索引中的这个"指针"。也就是说行的位置（实现中经过16K的Page来定位，后面会涉及）会随着数据库里数据的修改而发生变化（前面的B+树节点分裂以及Page的分裂），使用聚簇索引就能够保证无论这个主键B+树的节点如何变化，辅助索引树都不受影响。

3 Page结构

若是说前面的内容偏向于解释原理，那后面就开始涉及具体实现了。

理解InnoDB的实现不得不提Page结构，Page是整个InnoDB存储的最基本构件，也是InnoDB磁盘管理的最小单位，与数据库相关的全部内容都存储在这种Page结构里。Page分为几种类型，常见的页类型有数据页（B-tree Node）Undo页（Undo Log Page）系统页（System Page） 事务数据页（Transaction System Page）等。单个Page的大小是16K（编译宏UNIV_PAGE_SIZE控制），每一个Page使用一个32位的int值来惟一标识，这也正好对应InnoDB最大64TB的存储容量（16Kib * 2^32 = 64Tib）。一个Page的基本结构以下图所示：

每一个Page都有通用的头和尾，可是中部的内容根据Page的类型不一样而发生变化。Page的头部里有咱们关心的一些数据，下图把Page的头部详细信息显示出来：

咱们重点关注和数据组织结构相关的字段：Page的头部保存了两个指针，分别指向前一个Page和后一个Page，头部还有Page的类型信息和用来惟一标识Page的编号。根据这两个指针咱们很容易想象出Page连接起来就是一个双向链表的结构。

再看看Page的主体内容，咱们主要关注行数据和索引的存储，他们都位于Page的User Records部分，User Records占据Page的大部分空间，User Records由一条一条的Record组成，每条记录表明索引树上的一个节点（非叶子节点和叶子节点）。在一个Page内部，单链表的头尾由固定内容的两条记录来表示，字符串形式的"Infimum"表明开头，"Supremum"表明结尾。这两个用来表明开头结尾的Record存储在System Records的段里，这个System Records和User Records是两个平行的段。InnoDB存在4种不一样的Record，它们分别是1主键索引树非叶节点 2主键索引树叶子节点 3辅助键索引树非叶节点 4辅助键索引树叶子节点。这4种节点的Record格式有一些差别，可是它们都存储着Next指针指向下一个Record。后续咱们会详细介绍这4种节点，如今只须要把Record当成一个存储了数据同时含有Next指针的单链表节点便可。

User Record在Page内以单链表的形式存在，最初数据是按照插入的前后顺序排列的，可是随着新数据的插入和旧数据的删除，数据物理顺序会变得混乱，但他们依然保持着逻辑上的前后顺序。

把User Record的组织形式和若干Page组合起来，就看到了稍微完整的形式。

如今看下如何定位一个Record：

1 经过根节点开始遍历一个索引的B+树，经过各层非叶子节点最终到达一个Page，这个Page里存放的都是叶子节点。

2 在Page内从"Infimum"节点开始遍历单链表（这种遍历每每会被优化），若是找到该键则成功返回。若是记录到达了"supremum"，说明当前Page里没有合适的键，这时要借助Page的Next Page指针，跳转到下一个Page继续从"Infimum"开始逐个查找。

详细看下不一样类型的Record里到底存储了什么数据，根据B+树节点的不一样，User Record能够被分红四种格式，下图种按照颜色予以区分。

1 主索引树非叶节点（绿色）

1 子节点存储的主键里最小的值（Min Cluster Key on Child），这是B+树必须的，做用是在一个Page里定位到具体的记录的位置。

2 最小的值所在的Page的编号（Child Page Number），做用是定位Record。

2 主索引树叶子节点（黄色）

1 主键（Cluster Key Fields），B+树必须的，也是数据行的一部分

2 除去主键之外的全部列（Non-Key Fields），这是数据行的除去主键的其余全部列的集合。

这里的1和2两部分加起来就是一个完整的数据行。

3 辅助索引树非叶节点非（蓝色）

1 子节点里存储的辅助键值里的最小的值（Min Secondary-Key on Child），这是B+树必须的，做用是在一个Page里定位到具体的记录的位置。

2 主键值（Cluster Key Fields），非叶子节点为何要存储主键呢？由于辅助索引是能够不惟一的，可是B+树要求键的值必须惟一，因此这里把辅助键的值和主键的值合并起来做为在B+树中的真正键值，保证了惟一性。可是这也致使在辅助索引B+树中非叶节点反而比叶子节点多了4个字节。（即下图中蓝色节点反而比红色多了4字节）

3 最小的值所在的Page的编号（Child Page Number），做用是定位Record。

4 辅助索引树叶子节点（红色）

1 辅助索引键值（Secondary Key Fields），这是B+树必须的。

2 主键值（Cluster Key Fields），用来在主索引树里再作一次B+树检索来找到整条记录。

下面是本篇最重要的部分了，结合B+树的结构和前面介绍的4种Record的内容，咱们终于能够画出一幅全景图。因为辅助索引的B+树与主键索引有类似的结构，这里只画出了主键索引树的结构图，只包含了"主键非叶节点"和"主键叶子节点"两种节点，也就是上图的的绿色和黄色的部分。

把上图还原成下面这个更简洁的树形示意图，这就是B+树的一部分。注意Page和B+树节点之间并无一一对应的关系，Page只是做为一个Record的保存容器，它存在的目的是便于对磁盘空间进行批量管理，上图中的编号为47的Page在树形结构上就被拆分红了两个独立节点。

至此本篇就算结束了，本篇只是对InnoDB索引相关的数据结构和实现进行了一些梳理总结，并未涉及到Mysql的实战经验。这主要是基于几点缘由：

1 原理是基石，只有充分了解InnoDB索引的工做方式，咱们才有能力高效的使用好它。

2 原理性知识特别适合使用图示，我我的很是喜欢这种表达方式。

3 关于InnoDB优化，在《高性能Mysql》里有更加全面的介绍，对优化Mysql感兴趣的同窗彻底能够本身获取相关知识，我本身的积累还未达到能分享这些内容的地步。