索引（Index）是帮助MySQL高效获取数据的数据结构，所以其本质：索引是数据结构，我们使用索引的目的自然是希望查询数据的速度能尽可能的快。我们在介绍MySQL索引实现之前，首先先来了解一下与之相关的数据结构。
二叉搜索树
目前大部分数据库系统及文件系统都采用B-Tree或其变种B+Tree作为索引结构，在说B-Tree之前，我们先介绍下二叉搜索树以及平衡二叉树，对于二叉搜索树我们应该都非常的清楚，所以我们这里简单快速的来看一下：
- 所有非叶子结点至多拥有两个子节点（ Left 和 Right ）
- 所有结点存储一个关键字
- 非叶子结点的左指针指向小于其关键字的子树，右指针指向大于其关键字的子树
如果二叉搜索树的所有非叶子结点的左右子树的结点数目均保持差不多，那么B树的搜索性能逼近二分查找；但是万一它的左右子数的节点数目相差巨大，那么它的搜索性能就会急剧下降，甚至可能和线性一致，如下
AVL Tree
那么什么是平衡二叉树（AVL Tree）呢？
- 父节点的左子树和右子树的高度之差不能大于1，也就是说不能高过1层，否则该树就失衡了，此时就要旋转节点，在编码时，我们可以记录当前节点的高度，比如空节点是0，叶子节点是1，非叶子节点的height往根节点递增
- 它的左子树和右子树都是平衡二叉树
我们以上述线性的二叉树为例，其过程如下：
在二叉树的基础上，满足任何节点的两个子树的高度最大差为1。如果AVL树在进行插入或者删除节点的时候，打破了平衡二叉树的两个子树高度最大差为1的条件，就会导致AVL树失去平衡。AVL树失去平衡之后，可以通过旋转使其恢复平衡。
旋转规则请自行百度，这里推荐一个网站 https://www.cs.usfca.edu/~galles/visualization/Algorithms.html，可以动态地查看平衡二叉树的旋转过程，这个网站中还包括了其中各种的数据结构等。
B-Tree
这里我们主要来了解的是我们的B-Tree和B+Tree，首先看其B-Tree，B-Tree即平衡多路查找树，B-Tree是为磁盘等外部存储设备设计的一种平衡查找树。
系统从磁盘读取数据到内存是以磁盘块（block）为基本单位的，位于同一个磁盘块的数据被一次性读取出来，而不是需要什么取什么。InnoDB存储引擎中有页（page）的概念，页是其磁盘管理的最小单位。
InnoDB存储引擎中默认每个页的大小为16kb，可通过参数 innodb_page_size 将页的大小设置为4k、8k、16k，在MySQL中可通过以下命令查看页的大小：show variables like 'innodb_page_size';
系统中一个磁盘块的存储空间往往没有那么大，因此InnoDB每次申请磁盘空间时都会是若干个地址连续磁盘块来达到页16kb。InnoDB在把磁盘数据读入到磁盘时会以页为基础单位，在查询数据时如果一个页中的每条数据都能有助于定位其他数据记录的位置，这将减少磁盘I/O次数，提高查询效率。B-Tree中的每个节点根据实际情况可以包含大量的关键字信息和分支。
一个M阶B树具有如下属性：
- 定义任意非叶子结点最多只有M个子节点；且M>2
- 根结点的子结点数为[2, M]（即：如果根节点不是叶结点，则最少有两个孩子）
- 除根结点以外的非叶子结点的儿子数为[M/2, M]
- 每个结点存放至少 M/2-1（取上整）和至多 M-1 个关键字；（至少2个关键字）
- 非叶子结点的关键字个数 = 指向子节点的指针个数-1
- 非叶子结点的关键字：K[1], K[2], …, K[M-1]；且K[i] < K[i+1]
- 非叶子结点的指针：P[1], P[2], …, P[M]；其中P[1]指向关键字小于K[1]的子树，P[M]指向关键字大于K[M-1]的子树，其它P[i]指向关键字属于(K[i-1], K[i])的子树
- 所有叶子结点位于同一层
B-树的搜索，从根结点开始，对结点内的关键字（有序）序列进行二分查找，如果命中则结束，否则进入查询关键字所属范围的子结点；重复，直到所对应的子结点指针为空，或已经是叶子结点
B-Tree的特性：
- 关键字集合分布在整颗树中
- 任何一个关键字出现且只出现在一个结点中
- 搜索有可能在非叶子结点结束
- 其搜索性能等价于在关键字全集内做一次二分查找
- 自动层次控制
B+Tree
B-Tree有许多变种，其中最常见的是B+Tree，例如MySQL就普遍使用B+Tree实现其索引结构。
B+Tree相对于B-Tree有几点不同：
- 非叶子结点只存储键值信息
- 所有叶子结点之间都有一个链指针
- 数据记录都存放在叶子结点中
- 每个结点的指针上限为2M而不是2M+1
我们在B-Tree中说过了在把磁盘数据读入到磁盘时会以页为基础单位，而每一个页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时同样会导致B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率。
而在B+Tree中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低B+Tree的高度。
另外在B+Tree的每个叶子节点增加一个指向相邻叶子节点的指针，就形成了带有顺序访问指针的B+Tree。做这个优化的目的是为了提高区间访问的性能，
MySQL索引实现
在MySQL中，索引属于存储引擎级别的概念，不同存储引擎对索引的实现方式是不同的，这里主要讨论MyISAM和InnoDB两个存储引擎的索引实现方式。
我们先介绍几种常见的索引分类：
- 普通索引： 即一个索引只包含单个列，一个表可以有多个单列索引
- 唯一索引： 索引列的值必须唯一，但允许有空值
- 主键索引： 设定为主键后数据库会自动建立索引，InnoDB为聚簇索引
- 复合索引： 即一个索引包含多个列
- 聚簇索引： 并不是一种单独的索引类型，而是一种数据存储方式。具体细节取决于不同的实现，InnoDB的聚簇索引其实就是在同一个结构中保存了B-Tree索引(技术上来说是B+Tree)和数据行。
- 非聚簇索引： 不是聚簇索引的索引，就是非聚簇索引
基本语法：
- 查看索引
show index from 表名;
- 创建索引
create [unique] index 索引名 on 表名(列名);alter table 表名 add [unique] index 索引名(列名);
其中还可以使用primary key来设置主键索引，使用fulltext 索引名来设置全局索引
- 删除索引
drop index 索引名 on 表名;
MyISAM索引实现
MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址。下图是MyISAM索引的原理图：
这里设表一共有三列，假设我们以Col1为主键，则上图则是一个MyISAM表的主索引（Primary key）示意图，可以看出MyISAM的索引文件仅仅保存数据记录的地址。
在MyISAM中，主索引和辅助索引（Secondary key）在结构上没有任何区别，只是主索引要求key是唯一的，而辅助索引的key可以重复。如果我们在Col2上建立一个辅助索引，则此索引的结构如下图所示：
同样也是一颗B+Tree，data域保存数据记录的地址。因此，MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。
InnoDB索引实现
虽然InnoDB也使用B+Tree作为索引结构，但具体实现方式却与MyISAM截然不同。
第一个重大区别是InnoDB的数据文件本身就是索引文件。从 MySQL逻辑架构及存储引擎 中知道，MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。
而在InnoDB引擎中其数据文件和索引文件是在同一个文件中进行存储的，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。
上图是InnoDB主索引（同时也是数据文件）的示意图，可以看到叶节点包含了完整的数据记录。这种索引叫做聚集索引。
因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有），如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。
第二个与MyISAM索引的不同是InnoDB的辅助索引data域存储相应记录主键的值而不是地址。换句话说，InnoDB的所有辅助索引都引用主键作为data域。例如下图为定义在Col3上的一个辅助索引：
聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。
另外了解了上述的内容，我们就知道了InnoDB的索引实现后，为什么不建议使用过长的字段作为主键，因为所有辅助索引都引用主索引，过长的主索引会令辅助索引变得过大。
还有就是用非单调的字段作为主键在InnoDB中不是个好主意，因为InnoDB数据文件本身是一颗B+Tree，非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。
最后本文参考了MySQL索引背后的数据结构及算法原理一文