Postgres对索引列的简单选择太慢了答案

【问题标题】：Postgres simple select on indexed column is too slowPostgres对索引列的简单选择太慢了
【发布时间】：2020-03-25 07:03:08
【问题描述】：

我有一张如下表。我有一个复合主键。我也为辅助键添加了索引。当我运行简单查询时，性能有点慢。例如

CREATE TABLE item_ka_preview_relation (
    item_id varchar(40) NOT NULL,
    item_type varchar(40) NOT NULL,
    ka_id varchar(40) NOT NULL,
    sequence_number int4 NULL,
    creation_date timestamp NOT NULL,
    last_modified_date timestamp NOT NULL,
    pp_association_by_rule bool NULL DEFAULT false,
    CONSTRAINT item_ka_relation_preview_pkey PRIMARY KEY (item_id,ka_id),
    CONSTRAINT item_ka_relation_preview_item_type_fkey FOREIGN KEY (item_type) REFERENCES item_type(id)
);
CREATE INDEX idx_itemkarelation_preview_itemtype ON item_ka_preview_relation (item_type DESC) ;
CREATE INDEX idx_itemkarelation_preview_kaid ON item_ka_preview_relation (ka_id DESC) ;

该表有 100 万行。下面的查询获取了大约 80k 行。

explain analyze
select * from item_ka_preview_relation ik where ik.ka_id in ('3800042','69104128','2300023','3800019','5400264','3800039')

分析是这样的

Bitmap Heap Scan on item_ka_preview_relation ik  (cost=5867.27..20251.85 rows=255062 width=54) (actual time=23.029..115.286 rows=250064 loops=1)
  Recheck Cond: ((ka_id)::text = ANY ('{3800042,69104128,2300023,3800019,5400264,3800039}'::text[]))
  Heap Blocks: exact=8490
  ->  Bitmap Index Scan on idx_itemkarelation_preview_kaid  (cost=0.00..5803.50 rows=255062 width=0) (actual time=21.741..21.742 rows=250064 loops=1)
        Index Cond: ((ka_id)::text = ANY ('{3800042,69104128,2300023,3800019,5400264,3800039}'::text[]))
Planning time: 0.328 ms
Execution time: 160.677 ms

虽然我已经索引了 ka_id 列，但查询仍然使用 Bitmap Heap Scan 并且响应很慢

任何改善这一点的想法。我正在使用 postgres 9.6.1

【问题讨论】：

160 毫秒（0.16 秒）似乎还不错。您需要多快？
@a_horse_with_no_name 查询的成本似乎更高。所以我认为当我加入其他表时可能是一些性能问题。
不要看成本，看执行时间和它需要多少缓冲区才能得到结果。索引使用对我来说似乎很好

标签： sql postgresql query-performance

【解决方案1】：

位图索引扫描实际上使查询更快。之所以选择它是因为有很多结果行。

您可以通过将enable_seqscan 和enable_bitmapscan 设置为off 来进行测试，并检查这是否会缩短执行时间。

如果是这样，也许您应该将effective_cache_size 调高和/或random_page_cost 调低，以使其与您的实际硬件相匹配。

【讨论】：

有效成本大小为 8115688kB，random_page_cost 为 4。是一个好数字吗？
如果您有 8GB RAM 和旋转磁盘，可能是的。玩它。