PostGreSQL不同索引类型(btree & hash)的性能问题

在关系型数据库调优中，查询语句涉及到的索引类型是不得不考虑的一个问题。不同的类型的索引可能会适用不同类型的业务场景。这里我们所说的索引类型指的是访问方法（Access Method），至于从其他维度区分索引(Index)这里暂不作考虑。

PostGresql数据库默认的索引访问方法是btree,其他的数据库如Oracle默认也是btree。那么btree到底是何方神圣呢？如果想要深入理解btree的运行原理，需要了解一下数据结构相关的知识，特别是树形数据结构。btree运用了b+ 树数据结构，其可以有效节省IO操作，在查询时可以提供查询效率。

 

我们沿用之前文章用过的查询语句来做测试，其中sort_test表有500万行数据。表创建sql和查询语句如下：

CREATE TABLE public.sort_test
(
    id bigint NOT NULL,
    salary numeric NOT NULL,
    CONSTRAINT sort_test_pkey PRIMARY KEY (id)
)

TABLESPACE pg_default;


explain analyze select * from public."sort_test" where salary = 101;

那么执行计划的细节如下图所示：

 

 下面将在同样的表字段上，删除原来的索引，添加相应的hash索引。添加语句为：

CREATE INDEX index_sort_test_salary_hash
    ON public.sort_test USING hash
    (salary)
    TABLESPACE pg_default;

添加完之后，如下图所示：

 

 

同样的查询语句的执行计划是怎样的呢？如下图：

 

 

可以发现0.757 ms  vs. 0.022 ms还是有数量级的差别,在这种情况下，hash索引的效率比btree的效率要高很多。由于hash索引结构的特殊性，其检索效率非常高，可以一步到位。而一般使用的B-tree索引需要从根节点->枝节点->页节点。所以从工作模式上看，hash索引的效率要比btree索引要高。

但是我们大家都懂的，事务都有两面性，hash索引有一定的限制和弊端，要不然这些常用的数据库如Oracle, MysqL,PostGresql等也不会将btree access method设置为默认选项了。具体有如下2点限制：

• Hash索引只能满足"=","IN"等，等值查询，不能使用范围查询。

• 在使用部分索引键查询的时候，hash索引将不起作用。

 

所以在应用不同的索引类型时，要充分考虑具体的业务场景和实际情况，才能得到更优解。