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」，會有更多性能測試相關內容分享。