如果一个表几乎完全驻留在内存中，执行查询最快的方法就是使用哈希索引。InnoDB有一个自动机制，它监视一个索引的使用情况。如果InnoDB注意到查询会从建立一个哈希索引中获益，它会自动地这么做，无须DBA人工加以干涉。

注意，哈希索引总是基于表上已存在的B树索引来建立的。InnoDB会在为该B树定义的键的一个前缀上建立哈希索引，不管该键有多长。哈希索引可以是部分的：它不要求整个B树索引被缓存在缓冲池中。InnoDB根据需要对被经常访问索引的那些页面建立哈希索引。

通常情况下，哈希索引可以提高查询性能，但是，在高并发情况下，会造成 RW-latch争用，进而堵塞进程。可以使用命令“show engine innodb status\G;”来监控SEMAPHORES，如果发现有很多waits，那么就应该关闭该功能，从而提升系统性能。

下面是一个测试机的情况：
SEMAPHORES信息如下：
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 38019, signal count 29541
Mutex spin waits 26137, rounds 282623, OS waits 7904
RW-shared spins 25122, rounds 637286, OS waits 17326
RW-excl spins 4071, rounds 400926, OS waits 12336
Spin rounds per wait: 10.81 mutex, 25.37 RW-shared, 98.48 RW-excl
INSERT BUFFER AND ADAPTIVE HASH INDEX信息如下：
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 29, seg size 31, 2 merges
merged operations:
 insert 1, delete mark 2, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 1245217, node heap has 12 buffer(s)
2765.81 hash searches/s, 2513.37 non-hash searches/s

可以看到，waits的次数并不是很多，且使用哈希索引的比例为50%，那么就不用关闭自适应哈希索引。

关于自适应哈希索引的介绍，请参见MySQL5.5手册：