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

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

这些限制导致了只有在特殊的情况下才能使用Hash索引。然而，它们如果符合了应用的需求，性能就会有梦幻般的提升。一个例子是关于数据仓库的，经典的star shema需要很多连接来查找表。Hash索引可以准确的找到哪张表是所需的。

　　除了Memory存储引擎是hash索引，NDB集群存储引擎也支持唯一的hash索引。这个功能主要针对于NDB集群索引，已经超出了本书的范围。

　　创建自己的hash索引

　　如果存储引擎不支持hash索引，你可以在InnoDB中自己来模拟创建它们。将会给你一些可以有权访问的hash索引的可取的属性。比如对于非常长的键，一个非常小的索引。

　　思路很简单：在B-Tree索引之上创建一个伪Hash索引。它和准确的Hash索引有些不同，因为它还是使用B-Tree索引来查找。然而，它会使用键的hash值去查找，而不是键自己本身。你所要做的就是在WHERE条件中手动指定Hash函数。

　　一个比较合适的例子就是URL的查找。URL经常会使B-TREE索引非常之大，因为它们太长了。一般来说，你查询URL的语句如下：

　　mysql> SELECT id FROM url WHERE url="http://www.mysql.com";

　　但是如果你删了url列的索引，并且在url_crc列添加一个索引。你可能使用的查询语句如下：

mysql> SELECT id FROM url WHERE url="http://www.mysql.com"
-> AND url_crc=CRC32("http://www.mysql.com);

　　这样做会非常好，因为MySQL语句优化器会发现url_crc上的索引，然会在索引中查找这个值（这个例子中 为1560514994）。即使有很多的行的url_crc相同，它也会通过整数比较的方法非常容易找到这些行，然后在检查它们，找到符合的URL.可选的方案是对url加索引，这会非常的慢。