索引的底层原理（三）

• • 哈希索引
  • InnoDB自适应哈希索引

哈希索引

memory存储引擎支持的是哈希索引，memory是支持内存的存储引擎。

哈希表中的元素没有任何顺序可言，只能进行等值比较，包括范围搜索、前缀搜索like、order by排序这些操作，哈希索引都不适合。

哈希索引无法处理磁盘上的数据，加载到内存上构建高效的搜索数据结构。

只适合做等值搜索，其他的范围、排序等不合适。

只能是做一些数据不落盘的操作

当被问到是否了解B+索引和哈希索引时，请把重点先放到B+树索引上。

InnoDB自适应哈希索引

对于MySQL5.7一些比较重要的描述：

1. 自适应哈希索引系统会进行分区，这是因为如果要在一个桶中进行并行的操作，那就要对这个桶加锁，维护线程安全，但是加锁就会阻塞线程；如果线程在不同的桶中进行操作，那么就不会出现竞态条件，也就不用加锁；
2. 自适应哈希索引总是基于二级索引树（B+树）上的二级索引值来构建的，目的是为了加速查找
3. 我们可以监控自适应哈希索引的使用，根据几个重要的参数信息来判断是否要关掉自适应哈希索引

实际业务中如果出现大量像·“where后面跟着索引字段的等值查询“这样的情况，那如果存储引擎依然基于二级索引树进行搜索，找到key所对应的主键（比如uid），然后再到主键索引树中进行搜索找到主键所对应的数据，大量这样的回表操作也会降低查询的速度。

所以InnoDB存储引擎设计了针对的优化策略，当InnoDB存储引擎监测到同样的二级索引不断被使用（进行等值比较），那么它会根据这个二级索引，在内存上根据二级索引树上的二级索引值，在内存上构建一个哈希索引（链式哈希表，只支持等值查询），来加速搜索（哈希索引查询的时间复杂度为O(1)），其中每个哈希桶上存储的就是数据的地址，这样在下一次利用这个二级索引进行等值查询时，利用哈希索引就可以直接找到数据地址。

但是需要注意的是自适应哈希索引本身的数据维护也是要耗费性能的，并不是说自适应哈希索引在任何情况下都会提升二级索引的查询性能，根据参数指标，来具体分析是否打开或者关闭自适应哈希索引

show variables like 'innodb_adaptive_hash_index';

默认是开启自适应哈希索引的：

查看默认的分区数：

show variables like 'innodb_adaptive_hash_index_parts';

可以通过下面的语句看到两个比较重要的信息：

show engine Innodb status\G

1. RW-latch等待的线程数量（自适应哈希索引默认分配8个分区），同一个分区中等待的线程数量过多
   

2. 走自适应哈希索引搜索的频率（低）和二级索引树的频率（高）
   

   情况2就说明实际业务中这样的等值查询是比较少的，那维护自适应哈希索引也要耗费很多性能，不如就直接进行二级索引

出现以上两种情况，最好就把自适应哈希索引关闭掉。