MySQL索引之索引类型

在谈论索引时如果没有特别说明通常是指B-tree类型的索引，B-tree类型的索引意味着数据都是有序排列的。

B-tree索引

B-tree是多路平衡二叉树，它的特点如下：

• 每个叶子节点到根节点的距离都相同
• 叶子节点保存的是真实数据的地址指针
• 非叶子节点记录的是索引字段数据和对应叶子节点的指针

不同的存储引擎实现B-tree的方式也略有不同。例如常见的InnoDB引擎索引分为聚簇索引和非聚簇索引。聚簇索引的结构是叶子节点记录完整的行数据，而不是行数据的地址指针。非聚簇索引的结构是叶子节点记录聚簇索引的地址指针。只有主键是聚簇索引，其他索引都是非聚簇索引。

MySQL会把索引数据加载到内存，对于聚簇索引来说，获取完整的行数据的方式就从磁盘IO转变成了内存IO，可以极大的提高查询数据的性能。但缺点是当索引结构较大时，会提高内存的占用率。

B-tree索引支持的查询类型有支持全值匹配、匹配最左前缀、匹配范围值、精确匹配某一列并范围匹配另外一列

hash索引

哈希索引（hash index）基于哈希表实现，只有精确匹配索引所有列的查询才有效。
对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码（hashcode），哈希码是一个较小的值，并且不同键值的行计算出来的哈希码也不一样。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针。

冲突的hash值会用链表存储

索引自身只需存储对应的哈希值，所以索引的结构十分紧凑，这也让哈希索引查找的速度非常快。然而，哈希索引也有它的限制。

• 哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，所以大部分情况下这一点对性能的影响并不明显。
• 哈希索引数据并不是按照索引值顺序存储的，所以也就无法用于排序。
• 哈希索引也不支持部分索引列匹配查找，因为哈希索引始终是使用索引列的全部内容来计算哈希值的。例如，在数据列（A,B）上建立哈希索引，如果查询只有数据列A，则无法使用该索引。
• 哈希索引只支持等值比较查询，包括=、IN（）、＜=＞（注意<>和<=>是不同的操作）。也不支持任何范围查询，例如 WHERE price ＞ 100。
• 如果哈希冲突很多的话，查询和索引维护操作的代价也会很高。例如，如果在某个选择性很低（哈希冲突很多）的列上建立哈希索引，那么当从表中删除一行时，存储引擎需要遍历对应哈希值的链表中的每一行，找到并删除对应行的引用，冲突越多，代价越大。

全文索引

全文索引是一种特殊类型的索引，它查找的是文本中的关键词，而不是直接比较索引中的值。全文搜索和其他几类索引的匹配方式完全不一样。它有许多需要注意的细节，如停用词、词干和复数、布尔搜索等。全文索引更类似于搜索引擎做的事情，而不是简单的WHERE条件匹配。

在相同的列上同时创建全文索引和基于值的B-Tree索引不会有冲突，全文索引适用于MATCH AGAINST操作，而不是普通的WHERE条件操作。