Schema的优化和索引 - 索引的基础 - 索引的类型 - Hash索引2

Schema的优化和索引 - 索引的基础 - 索引的类型 - Hash索引2

要注意的是这个slot是有序的。但是行并不是有序。现在我们执行下面的查询

　　mysql> SELECT lname FROM testhash WHERE fname='Peter';

　　MySQL将会计算Peter的hash值，并且用它来找到索引中的指针。因为f(peter)=8784。MySQL会在索引中查找8784，也就找到了它的指针，指向行3。最后一步就是把行3的值和Peter做个比较。来确定是否是正确的行。

　　因为索引本身存储的就是比较短的Hash值，所以hash索引是压缩的。hasn值的长度和列的类型并没有什么关系。对一个tinyint创建一个hash索引的长度和一个值非常大列类型的长度是一样的。

　　因此查找是非常轻量和快速的。然而，hash索引有如下的限制：

　　因为索引仅仅包含了hash值和行的指针，而并不是数据本身，所以MySQL并不能使用在索引中的值，而去避免读取行。幸运的是，访问内存中的行是非常快的，因此一般来说不太会降低性能。

　　MySQL不能对排序使用hash索引。因为它们没有存储排序后的行。

　　Hash索引不支持部分键的匹配，因为它们计算的是整个索引值的hash值。所以如果你对（A,B）进行hash索引，并且你的查询仅仅以A的条件进行查询，此时Hash索引就会失效。

　　Hash索引只支持是否相等的一些比较。比如=，IN(),<=>操作都可以。（注意<>和<=>不是一样的）。它们不能加速范围查询。比如WHERE PRICE>100。

　　在hash索引访问数据是非常快速的，除非有一些冲突（许多值有相同的hash值）。当冲突出现的时候，存储引擎必须找到每个linked list中的指针所指向的行，并且比较这些行的值和要查找的值作比较，直到找到正确的行。

　　如果有许多hash值冲突，那么索引的维护操作将会非常慢。比如，如果你在一个列上创建了一个索引并且索引值冲突很多，那么之后你从表中删除一个行，从索引找到正确的指针的消耗是非常大的。存储引擎会在Linked list中查找具有相同hash值每一行的指针，然后找到了再删除这个要删除行的引用。