mysql btree和hash索引对比

只有 MEMORY 存储引擎的表才可以选择使用 BTREE 索引或者 HASH 索引，像我们 常用的innodb只支持btree索引 。两种不同类型的索引各有其不同的适用范围。

Hash索引只能用于对等比较，例如=,<=>（相当于=） *** 作符。时间复杂度是O(1)，一次查找便能定位数据，不像BTree索引需要从根节点到枝节点，最后才能访问到页节点这样多次IO访问，所以Hash在 单值查询 下检索效率远高于BTree索引。

但是，事实上我们更多情况是使用btree而不是hash

HASH 索引有一些重要的特征需要在使用的时候特别注意，如下所示。

下面我们可以进行验证：

创建一个city_memory表，其中 country_id字段上加了 HASH索引

插入数据

1、先开看这条等值条件sql

2、那么再来看 大于和小于条件sql

3、那么in这种范围条件呢？

in 条件对于hash来说是支持的，同样btree当然也支持。而且btree索引在使用in条件找数据时相对于hash性能更好，因为rows由4变为2（说明使用btree扫描2行即可找到）证明如下：

4、 BETWEEN .. AND .. 条件呢？

BETWEEN .. AND .. 条件在 不会用到hash索引！再来看看 btree的情况：

BETWEEN .. AND .. 条件能够使用到btree索引。

5、like 条件呢？

为了使用like条件，我们先将country_id类型改为 varchar

我们再来执行：

like条件会让hash索引失效。我们再来看btree下的like怎样：

好的，btree下也支持 like的不带开头%的访问查询

1、先来看hash索引支不支持排序

hash索引果然不能用在排序中，这多么致命呀！产生了 Using filesort文件内排序。性能上是个大坑。

2、同样，我们知道分组是要基于排序的。排序不使用索引，分组当然也不使用索引了。验证如下：

最终不仅没使用到索引，还产生了文件内排序和使用临时表。

当使用 MEMORY 引擎表的时候，如果是默认创建的 HASH索引，就要注意 SQL 语句的编写，确保可以使用上索引，如果索引字段需要 范围查询、排序、分组 就请使用btree索引；

1. hash索引查找数据基本上能一次定位数据，当然有大量碰撞的话性能也会下降。而btree索引就得在节点上挨着查找了，很明显在数据精确查找方面hash索引的效率是要高于btree的； 2. 那么不精确查找呢，也很明显，因为hash算法是基于等值计算的，

---