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”，会有更多性能测试相关内容分享。