概述MySQL支持很多存储引擎，每个存储引擎支持的索引都不一样。所以MySQL数据库支持很多索引类型，比如B树索引、B Tree索引、hash索引、全文索引等等。下面简单介绍一下这些指标的实现原理。

01仅哈希索引内存存储引擎支持哈希索引。Hash index通过索引列的值来计算值的hashCode，然后在hashCode对应的位置存储值所在行中数据的物理位置。因为使用了hash算法，访问速度很快，但是一个值只能对应一个hashCode，而且是hash的分布方式，所以hash索引不支持范围搜索和排序的功能。

简单来说，哈希索引就是利用某种哈希算法将键值转换成新的哈希值。搜索时不需要像B树一样从根节点到叶节点一步步搜索，只需要一个哈希算法就可以立即定位到对应的位置，速度非常快。

02全文索引(Full-text index)只能用于MyISAM和InnoDB。对于大型数据，生成全文索引会消耗大量空间时间。对于大型文本对象或CHAR类型的大型数据，如果使用公共索引，匹配文本的前几个字符仍然是可行的。但是如果要匹配文本中间的几个词，就要用LIKE %word%来匹配，这需要很长的时间时间处理，响应时间会大大增加。在这种情况下，您可以使用全文索引。

Sphinx -全文索引

可以在创建表时创建文本，也可以在需要时使用ALTER或CREATE INDEX添加文本：

//创建表时添加全文索引ctreatable表my _ table (id int (10)主键，name varchar (10) not null，my _ texttext，full text(my _ text))engine=myisam默认charset=UTF8//创建表后，必要时添加全文索引alter table my _ table add full text index ft _ index(column _ name)；全文索引查询也有自己的特殊语法，而不是LIKE%查询 string%的模糊语法查询。

select * from table _ name match(ft _ index)against('查询 string ')；注意：

*对于大型数据集，向没有全文索引的表中添加数据，然后添加全文索引，比向已经有全文索引的表中添加数据要快。MySQL版之前自带的全文索引只能用于MyISAM存储引擎。如果是其他数据引擎，那么全文索引就不会生效。5.6版本以后，InnoDB存储引擎开始支持全文索引*在MySQL中，全文索引脱离英文是有用的，但是目前不支持中文。5.7版本后，我们开始使用ngram插件支持中文。*在MySQL中，如果检索到的字符串太短，则无法检索到预期的结果。检索到的字符串至少有4个字节长。此外，如果检索到的字符包含停用词，则停用词将被忽略。0品种索引和B树索引1，B树索引

BTree是一种平衡搜索多叉树。设树的度为2d(d1)，高度为H，那么BTree必须满足以下条件：

每个叶节点的高度相同，等于H；每个非叶节点由n-1个键和n个指针点组成，其中d=n=2d，键和点相互间隔，节点的两端一定是键；叶指针都为空；非叶节点的键都是[key，data]的二元组，其中key表示作为索引的键，data是键值所在行的数据；BTree的结构如下：

在BTree的组织下，可以使用二分搜索法，搜索复杂度为h*log(n)。一般来说树的高度很小，一般在3左右，所以BTree是一种非常高效的搜索结构。

2.b树索引

树B是B树的变种。设d是树的度数，h是树的高度。树b和BTree的区别主要在于：

B树中的非叶节点不存储数据，只存储键值；

树b的叶节点没有指针，所有键值都会出现在叶节点上，key存储的键值对应数据的物理地址；

树b的每个非叶节点由n个键值key和n个指针点组成；

树B的结构如下：

3.B树相对于B树的优势

1)、磁盘读写成本较低。

一般来说，B树比B Tree更适合实现外存的索引结构，因为存储引擎的设计专家们巧妙地利用了外存(磁盘)的存储结构，即磁盘的最小存储单位是扇区，而操作系统的块通常是扇区的整数倍，操作系统以页为单位管理内存，默认一页通常是4K。数据库页面通常被设置为操作系统页面的整数倍，因此索引结构的节点被设计为一个页面的大小。然后利用外存的“预读”原理，每次读取时将整个节点的数据读入内存，然后在内存中进行搜索。众所周知，内存的读取速度是外存读取I/O速度的几百倍，所以提高查找速度的关键在于尽可能少的磁盘I/O。大家知道，每个节点的键越多，树的高度就越小，需要的I/O次数就越少。所以一般来说B树比B树快，因为B Tree的非叶节点不存储数据，可以存储更多的键。

2)，查询速度更稳定

由于B树的非叶节点不存储数据，所以所有数据对叶节点应该是查询，叶节点的高度是一样的，所以查询对所有数据的速度是一样的。

4.具有顺序索引的b树

很多存储引擎都是在B树的基础上进行优化，增加了指向相邻叶节点的指针，形成了一棵具有顺序访问指针的B树。这样做是为了提高在提高区间内搜索的效率。只要找到第一个值，就可以按顺序搜索后续的值。

树B的结构如下：

04聚簇索引和非聚簇索引以上主要是关于MySQL的索引结构的实现原理。接下来，让我们看看特定的存储引擎是如何实现索引结构的。MyISAM和InnoDB是MySQL中最常见的两个存储引擎，分别实现了非聚集索引和聚集索引。

聚簇索引的解释是，聚簇索引的顺序就是数据的物理存储顺序。

对非聚集索引的解释是，索引顺序与数据的物理顺序无关。

首先要介绍几个概念。在索引的分类中，我们可以根据索引的键是否为主键，将其分为“一级索引”和“二级索引”。利用主键的键值建立的索引称为“一级索引”，其他称为“二级索引”。因此，只能有一个一级索引和多个二级索引。

1.MyISAM——非聚集索引

MyISAM存储引擎使用非聚集索引。非聚集索引的主索引和次索引几乎相同，只是主索引不允许重复或为空，它们的叶节点的键都存储键值对应的数据的物理地址。

Myisam(非聚集)表分布

非聚集索引的数据表和索引表是分开存储的。

非聚集索引中的数据根据数据的插入顺序保存。因此，非聚集索引更适合于单个数据查询。插入顺序不受键值的影响。

全文索引只能在MyISAM中使用。(innoDB在mysql5.6之后也支持全文索引)

*起初，我不明白为什么非聚集索引的主索引和次索引指向相同的内容，还需要次索引。后来才知道索引不是用来查询的，是用在那些地方的。不就是在WHERE和ORDER BY语句后面吗？那么查询的条件不是主键怎么办？这时候就需要二级索引了。

2.InnoDB——集群索引

聚簇索引的主索引的叶节点存储键值本身对应的数据，次索引的叶节点存储键值对应的数据的主键值。因此，主键的值长度越小越好，类型也越简单。

InnoDB(集群)表分布

聚集索引的数据与主键索引一起存储。

聚集索引的数据是按照主键的顺序存储的。所以适合按主键索引的区间进行搜索，可以少一些磁盘I/O，加快速度查询。但是，为此，最好按照主键的单调顺序插入聚集索引，否则会频繁造成页面拆分，严重影响性能。

在InnoDB中，如果只需要查找索引的列，尽量不要添加其他列，这样会提高查询高效。

*使用主索引时，使用聚集索引更合适，因为聚集索引只需要搜索一次，而非聚集索引需要在找到数据的地址后对数据进行I/O搜索。

*由于聚集二级索引存储的是主键的键值，所以在数据行移动或页拆分时可以降低开销，因为此时不需要维护二级索引。但是，由于主索引本身存储数据，聚集索引将占用更多空间。

*在插入新数据时，聚集索引比非聚集索引慢很多，因为在插入新数据时，需要检查主键是否重复，这需要遍历主索引的所有叶节点，而非聚集索引的叶节点存储数据地址，占用空间较少，所以分布比较集中。At查询，I/O较少，但数据本身存储在聚集索引的主索引中，占用空间更大，分布范围更广。

3.聚集索引和非聚集索引的区别

下图生动地说明了聚集索引和非聚集索引之间的区别：

从上图可以看出，聚簇索引的二级索引的叶节点的数据存储的是主键的值，一级索引的叶节点的数据存储的是数据本身，也就是说数据和索引是存储在一起的，索引查询到达的地方是数据本身，所以索引和数据本身的顺序是一样的；

而非聚集索引的一级索引和二级索引的叶节点的数据是存储数据的物理地址，也就是说索引和数据不是存储在一起的，数据的顺序和索引的顺序无关，也就是说索引的顺序和数据的物理顺序无关。

PS:PS:MyISAM和innoDB的区别总结如下：

总结InnoDB支持事务、行级锁、B树、全文等索引，不支持哈希索引；

MyISAM不支持事务，支持表级锁，支持B树、全文等索引，不支持哈希索引；

另外，内存不支持事务，支持表级锁，支持B树、Hash等索引，不支持全文索引；

后面会分享更多关于devops和DBA的内容，感兴趣的朋友可以关注一下~