为什么在同一个查询中，散列索引被忽略，而btree索引被使用

Question

我认为这两种情况都只需要扫描索引，但事实并非如此。仅使用BTree索引。

以下是的示例

drop table if exists test;
create table test
(
id    serial4 primary key,
name  varchar(255) not null,
score int          not null
);

我插入了1000000行。9867行得分为0。

使用哈希索引进行解释

drop index if exists test_score_zero;
create index test_score_zero on test using hash (id) where score = 0;
explain select id from test where score = 0;

用BTree索引解释

drop index if exists test_score_zero;
create index test_score_zero on test using btree (id) where score = 0;
explain select id from test where score = 0;

哈希索引结果为

Gather  (cost=1000.00..13578.03 rows=9867 width=4)
Workers Planned: 2
->  Parallel Seq Scan on test  (cost=0.00..11591.33 rows=4111 width=4)
Filter: (score = 0)

BTree Indexes结果为

Index Only Scan using test_score_zero on test  (cost=0.29..262.58 rows=9867 width=4)

PostgreSQL版本：

psql (PostgreSQL) 12.5 (Ubuntu 12.5-1.pgdg18.04+1)

Answer 1

如手册中所述，散列索引根本不支持"仅索引扫描"；

为了解决这个性能问题，PostgreSQL支持仅索引扫描〔…〕

索引类型必须支持仅索引扫描。B树索引总是这样。GiST和SP GiST索引只支持某些运算符类的索引扫描，而不支持其他运算符类其他索引类型不支持。

^(强调矿(

使用哈希索引而不是B-树索引的原因非常少，如果您希望"仅索引扫描"将大大提高查询性能，请使用B-树索引。