【转】PostgreSQL Index性能调优

Index(索引)这个概念对于很多熟悉关系型数据库的人来说，不是一个陌生的概念。当表中数据越来越多时，在查询时，为了避免全表查询（sequence scan)可以在查询相关的条件字段上添加索引。举例来说明index对于查询效率的影响。首先创建测试表 "sort_test"，如下时表创建SQL，可以发现此表有2个字段id和salary。其中id是主键，我们知道属于主键的字段是默认添加了索引的。

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

TABLESPACE pg_default;

ALTER TABLE public.sort_test
    OWNER to postgres;

以以下SQL查询语句为例进行讲解，其中查询字段salary上没有创建索引。

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

那么此时的执行计划和执行时间是多少呢，可以参考下图，执行计划是走Parallel Seq Scan，SQL运行时间是 246.71 ms.

那么如果要在salary字段上添加索引呢?创建索引的语句如下：

CREATE INDEX index_sort_test_salary
    ON public.sort_test USING btree
    (salary ASC NULLS LAST)
    TABLESPACE pg_default;

salary应用索引之后的执行计划如何呢？可以参考下图，执行时间为0.047 ms，执行时间有了大幅度提升，大致提升了5200多倍。所以在大容量表中，查询时，如果有性能问题，首先要检查相关的字段有没有创建或者走索引。测试表的容量是500万行。

如果是小容量的表或者表不会发生很多的查询操作，反而会有很多的插入/更新操作，那么此时就要对创建索引这件事慎重了。

那么很多同学可能会中途接手项目，对于表结构的历史不是特别熟悉，那么对于一个很大的项目，表结构可能也比较复杂，那么应该怎么去快速定位哪些索引很少用呢？可以参考如下SQL,如何查询结果是0，那么可以考虑将相关索引删除。

select idx_scan from pg_stat_user_indexes where indexrelname = 'index_sort_test_salary';

个人的建议是极少用到的索引可以删除，留下无用的索引可能会造成其他类型的操作性能问题，还有就是索引也会占用磁盘空间的。

本文转自公众号【TimTest】，原文地址：https://mp.weixin.qq.com/s?__biz=MzI2OTYwMDc0MQ==&mid=2247483688&idx=1&sn=ba8832896b46e64c644357e25c000904&chksm=eadc93a2ddab1ab44901584e686ef41203cdbd2e5f2df8a770aac3fd426bf48a870f1899b73a&token=2021082705&lang=zh_CN#rd