5分钟快速了解MySQL索引的各种类型

在MySQL中，存储引擎也是用了类似的方法，先在索引中找到对应的值，然后再根据匹配的索引值找到对应表中记录的位置。

面试中为什么问索引？

之所以在索引在面试中经常被问到，就是因为：索引是数据库的良好性能表现的关键，也是对查询能优化最有效的手段。索引能够轻易地把查询性能提高几个数量级。

然而，糟糕的索引也同样会影响查询性能，当表中的数据量越来越多的时候，索引对性能的影响就越大。在数据量比较少并且负责比较低的时候，糟糕的索引对性能的影响可能不明显，但是当数据量逐渐增多的时候，性能会急剧下降。

索引的类型

经过前面的介绍，我们就进入正题，了解一下MySQL支持的索引类型，以及它们的原理和用法。

不同类型的索引，可以为不同场景提供更好的性能。在MySQL中，索引是在存储引擎层面实现的，而不是在服务器层面实现的。正如大家所知道，MySQL支持多种类型的存储引擎。所以，在不同存储引擎中索引的实现方式并不是一样的，也不是所有类型的索引都被所有存储引擎支持的，即使多个存储引擎支持同一种类型的索引，它底层的实现也有可能是不相同的。

B-Tree索引

B-Tree索引是被大多数MySQL存储引擎支持的，在我们讨论索引时，假如没有特别地说明类型，那么大概率说的就是B-Tree索引了。我们使用B-Tree这个词，是因为MySQL在创建表和其他语句中就使用这个关键字。

然而，在不同存储引擎的底层可能使用不同的数据结构和算法，比如：InnoDB存储引擎内部使用的是B+Tree结构，NDB集群存储引擎内部使用的是T-Tree结构。不同存储引擎用以不同的方式使用B-Tree索引，性能也可能不同，比如：InnoDB的索引上存储的是原数据格式，而MyISAM存储引擎使用前缀压缩技术使索引更小，InnoDB索引的行存储的数据行的主键引用，而MyISAM存储引擎的索引的行存储的是数据行的物理位置。

B-Tree索引的原理

B-Tree索引能够加快访问数据的速度，因为不需要全表扫描就可以快速检索的需要的数据。那么B-Tree索引是怎么做到的呢？我们通过一个简单的例子了解一下InnoDB的B-Tree索引是怎么工作的：

CREATE TABLE om_address (

province_name varchar(255) NOT NULL COMMENT ‘省’,

city_name varchar(255) NOT NULL COMMENT ‘市’,

district_name varchar(255) NOT NULL COMMENT ‘区’,

detailed_address varchar(255) NULL DEFAULT NULL COMMENT ‘详细地址’,

INDEX index_province_city_district(province_name, city_name, district_name) USING BTREE

) ENGINE = InnoDB;

这个表中共有4个字段，分别表示省、市、区和详细地址，还有一个B-Tree索引，其中包含了省、市、区三个字段。因为索引的所有值都是按照顺序存储的，即：节点的左子树比当前节点小，节点的右子树比当前节点大。那么当查询数据时，从索引的根节点开始搜索，根据比较当前节点的索引值向子树进行查找，直到找到对应的索引值，或者根本没有找到。

B-Tree索引的用法

根据B-Tree索引的特点，它可以用于全值匹配、值范围匹配和最左前缀匹配。

• 全值匹配是指和索引中所有的字段进行匹配，比如：查询黑龙江省哈尔滨市南岗区的数据。

• 值范围匹配是指索引中字段的某一范围进行匹配，但是必须满足前面字段的全匹配，比如：第一个字段province_name省名称的全匹配，第二个字段city_name城市名称的范围匹配。

• 最左前缀匹配是指索引中字段的某一开头部分进行匹配，但是必须满足前面字段的全匹配，比如：第一个字段province_name省名称为内蒙古，第二个字段city_name城市名称以“呼”开头。

哈希索引

哈希索引是基于哈希表实现的，用于精确匹配索引所指向的数据。存储引擎对每一行数据的所有索引字段计算出一个哈希码，哈希码是一个比较小的值，并且不同的数据计算出来的哈希码一般情况下也不一样。哈希索引中存放了这个哈希码和指向这个数据行的指针。

在MySQL中，只有Memory存储引擎支持哈希索引，也是Memory存储引擎的默认索引类型。另外，在InnoDB存储引擎中也运用了哈希索引，叫做自适应哈希索引。当某些索引中被非常频繁的使用时，InnoDB存储引擎会在内存中基于B-Tree索引之上再创建一个哈希索引，这样一来使得B-Tree索引也具有的快速哈希查找的优点。