2. 程式人生 > >淺談PostgreSQL的索引

淺談PostgreSQL的索引

阿新 • • 發佈：2017-09-15
all b- command 唯一索引 rom hang ocs erb 5.6

1. 索引的特性

1.1 加快條件的檢索的特性

當表數據量越來越大時查詢速度會下降，在表的條件字段上使用索引，快速定位到可能滿足條件的記錄，不需要遍歷所有記錄。

create table t(id int, info text);
insert into t select generate_series(1,10000),‘lottu‘||generate_series(1,10000);
create table t1 as select * from t;
create table t2 as select * from t;
create index ind_t2_id on t2(id);
lottu=
 
# analyze t1;
ANALYZE
lottu=# analyze t2;
ANALYZE
# 沒有索引
lottu=# explain (analyze,buffers,verbose) select * from t1 where id < 10;
                                             QUERY PLAN                                              
-----------------------------------------------------------------------------------------------------
 

 Seq Scan on lottu.t1  (cost=0.00..180.00 rows=9 width=13) (actual time=0.073..5.650 rows=9 loops=1)
   Output: id, info
   Filter: (t1.id < 10)
   Rows Removed by Filter: 9991
   Buffers: shared hit=55
 Planning time: 25.904 ms
 Execution time: 5.741 ms
(7 rows)
# 有索引
lottu=# explain (analyze,verbose,buffers) select
 
 * from t2 where id < 10;
                                                     QUERY PLAN                                                      
---------------------------------------------------------------------------------------------------------------------
 Index Scan using ind_t2_id on lottu.t2  (cost=0.29..8.44 rows=9 width=13) (actual time=0.008..0.014 rows=9 loops=1)
   Output: id, info
   Index Cond: (t2.id < 10)
   Buffers: shared hit=3
 Planning time: 0.400 ms
 Execution time: 0.052 ms
(6 rows)

#在這個案例中：執行同一條SQL。t2有索引的執行數據是0.052 ms；t1沒有索引的是：5.741 ms;

1.2 有序的特性

索引本身就是有序的。

#沒有索引
lottu=# explain (analyze,verbose,buffers) select * from t1 where id > 2 order by id;
                                                   QUERY PLAN                                                    
-----------------------------------------------------------------------------------------------------------------
Sort  (cost=844.31..869.31 rows=9999 width=13) (actual time=8.737..11.995 rows=9998 loops=1)
   Output: id, info
   Sort Key: t1.id
   Sort Method: quicksort  Memory: 853kB
   Buffers: shared hit=55
   ->  Seq Scan on lottu.t1  (cost=0.00..180.00 rows=9999 width=13) (actual time=0.038..5.133 rows=9998 loops=1)
         Output: id, info
         Filter: (t1.id > 2)
         Rows Removed by Filter: 2
         Buffers: shared hit=55
 Planning time: 0.116 ms
 Execution time: 15.205 ms
(12 rows)
 #有索引
lottu=# explain (analyze,verbose,buffers) select * from t2 where id > 2 order by id;
                                                         QUERY PLAN                                                          
-----------------------------------------------------------------------------------------------------------------------------
 Index Scan using ind_t2_id on lottu.t2  (cost=0.29..353.27 rows=9999 width=13) (actual time=0.030..5.304 rows=9998 loops=1)
   Output: id, info
   Index Cond: (t2.id > 2)
   Buffers: shared hit=84
 Planning time: 0.295 ms
 Execution time: 7.027 ms
(6 rows)

#在這個案例中：執行同一條SQL。

  • t2有索引的執行數據是7.027 ms；t1沒有索引的是：15.205 ms;
  • t1沒有索引執行還占用了 Memory: 853kB。

2. 索引掃描方式

索引的掃描方式有3種

2.1 Indexscan

先查索引找到匹配記錄的ctid，再通過ctid查堆表

2.2 bitmapscan

先查索引找到匹配記錄的ctid集合，把ctid通過bitmap做集合運算和排序後再查堆表

2.3 Indexonlyscan

如果索引字段中包含了所有返回字段，對可見性映射 (vm)中全為可見的數據塊，不查堆表直接返回索引中的值。

這裏談談Indexscan掃描方式和Indexonlyscan掃描方式
對這兩種掃描方式區別；借用oracle中索引掃描方式來講；Indexscan掃描方式會產生回表讀。根據上面解釋來說；Indexscan掃描方式：查完索引之後還需要查表。 Indexonlyscan掃描方式只需要查索引。也就是說：Indexonlyscan掃描方式要優於Indexscan掃描方式？我們來看看

現有表t；在字段id上面建來ind_t_id索引
1. t表沒有VM文件。
lottu=# \d+ t
                           Table "lottu.t"
 Column |  Type   | Modifiers | Storage  | Stats target | Description 
--------+---------+-----------+----------+--------------+-------------
 id     | integer |           | plain    |              | 
 info   | text    |           | extended |              | 
Indexes:
    "ind_t_id" btree (id)

lottu=# explain (analyze,buffers,verbose) select id from t where id < 10;
                                                      QUERY PLAN                                                       
-----------------------------------------------------------------------------------------------------------------------
 Index Only Scan using ind_t_id on lottu.t  (cost=0.29..8.44 rows=9 width=4) (actual time=0.009..0.015 rows=9 loops=1)
   Output: id
   Index Cond: (t.id < 10)
   Heap Fetches: 9
   Buffers: shared hit=3
 Planning time: 0.177 ms
 Execution time: 0.050 ms
(7 rows)
#人為更改執行計劃
lottu=# set enable_indexonlyscan = off;
SET
lottu=# explain (analyze,buffers,verbose) select id from t where id < 10;
                                                    QUERY PLAN                                                    
------------------------------------------------------------------------------------------------------------------
 Index Scan using ind_t_id on lottu.t  (cost=0.29..8.44 rows=9 width=4) (actual time=0.008..0.014 rows=9 loops=1)
   Output: id
   Index Cond: (t.id < 10)
   Buffers: shared hit=3
 Planning time: 0.188 ms
 Execution time: 0.050 ms
(6 rows)
# 可以發現兩者幾乎沒有差異；唯一不同的是Indexonlyscan掃描方式存在掃描的Heap Fetches時間。 這個時間是不在Execution time裏面的。
2. t表有VM文件
lottu=# delete from t where id >200 and id < 500;
DELETE 299
lottu=# vacuum t;
VACUUM
lottu=# analyze t;
ANALYZE
lottu=# explain (analyze,buffers,verbose) select id from t where id < 10;
                                                      QUERY PLAN                                                       
-----------------------------------------------------------------------------------------------------------------------
 Index Only Scan using ind_t_id on lottu.t  (cost=0.29..4.44 rows=9 width=4) (actual time=0.008..0.012 rows=9 loops=1)
   Output: id
   Index Cond: (t.id < 10)
   Heap Fetches: 0
   Buffers: shared hit=3
 Planning time: 0.174 ms
 Execution time: 0.048 ms
(7 rows)

lottu=# set enable_indexonlyscan = off;
SET
lottu=# explain (analyze,buffers,verbose) select id from t where id < 10;
                                                    QUERY PLAN                                                    
------------------------------------------------------------------------------------------------------------------
 Index Scan using ind_t_id on lottu.t  (cost=0.29..8.44 rows=9 width=4) (actual time=0.012..0.022 rows=9 loops=1)
   Output: id
   Index Cond: (t.id < 10)
   Buffers: shared hit=3
 Planning time: 0.179 ms
 Execution time: 0.077 ms
(6 rows)

總結：

  • Index Only Scan在沒有VM文件的情況下, 速度比Index Scan要慢, 因為要掃描所有的Heap page。差異幾乎不大。
  • Index Only Scan存在VM文件的情況下，是要比Index Scan要快。

知識點1：

  • VM文件：稱為可見性映射文件；該文件存在表示：該數據塊沒有需要清理的行。即已經做了vaccum操作。

知識點2：

人為選擇執行計劃。可設置enable_xxx參數有

  • enable_bitmapscan
  • enable_hashagg
  • enable_hashjoin
  • enable_indexonlyscan
  • enable_indexscan
  • enable_material
  • enable_mergejoin
  • enable_nestloop
  • enable_seqscan
  • enable_sort
  • enable_tidscan

參考文獻

  • 參考德哥：《PostgreSQL 性能優化培訓 3 DAY.pdf》
  • https://www.postgresql.org/docs/9.6/static/runtime-config-query.html

3. 索引的類型

PostgreSQL 支持索引類型有: B-tree, Hash, GiST, SP-GiST, GIN and BRIN。

  • postgresql----Btree索引:http://www.cnblogs.com/alianbog/p/5621749.html
  • postgresql----hash索引：一般只用於簡單等值查詢。不常用。
  • postgresql----Gist索引:http://www.cnblogs.com/alianbog/p/5628543.html

4. 索引的管理

4.1 創建索引

創建索引語法：

lottu=# \h create index
Command:     CREATE INDEX
Description: define a new index
Syntax:
CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] name ] ON table_name [ USING method ]
    ( { column_name | ( expression ) } [ COLLATE collation ] [ opclass ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ] [, ...] )
    [ WITH ( storage_parameter = value [, ... ] ) ]
    [ TABLESPACE tablespace_name ]
    [ WHERE predicate ]
接下來我們以t表為例。    
1. 關鍵字【UNIQUE】
#創建唯一索引；主鍵就是一種唯一索引
CREATE UNIQUE INDEX ind_t_id_1 on t (id);
2. 關鍵字【CONCURRENTLY】
# 這是並發創建索引。跟oracle的online創建索引作用是一樣的。創建索引過程中；不會阻塞表更新，插入，刪除操作。當然創建的時間就會很漫長。
CREATE INDEX CONCURRENTLY ind_t_id_2 on t (id);
3. 關鍵字【IF NOT EXISTS】
#用該命令是用於確認索引名是否存在。若存在；也不會報錯。
CREATE INDEX IF NOT EXISTS ind_t_id_3 on t (id);
4. 關鍵字【USING】
# 創建哪種類型的索引。 默認是B-tree。
CREATE INDEX ind_t_id_4 on t using btree (id);
5 關鍵字【[ ASC | DESC ] [ NULLS { FIRST | LAST]】
# 創建索引是采用降序還是升序。 若字段存在null值，是把null值放在前面還是最後：例如采用降序，null放在前面。
CREATE INDEX ind_t_id_5 on t (id desc nulls first)
6. 關鍵字【WITH ( storage_parameter = value)】
#索引的填充因子設為。例如創建索引的填充因子設為75
CREATE INDEX ind_t_id_6 on t (id) with (fillfactor = 75);
7. 關鍵字【TABLESPACE】
#是把索引創建在哪個表空間。
CREATE INDEX ind_t_id_7 on t (id) TABLESPACE tsp_lottu;
8. 關鍵字【WHERE】
#只在自己感興趣的那部分數據上創建索引，而不是對每一行數據都創建索引，此種方式創建索引就需要使用WHERE條件了。
CREATE INDEX ind_t_id_8 on t (id) WHERE id < 1000;

4.2 修改索引

修改索引語法

lottu=# \h alter index
Command:     ALTER INDEX
Description: change the definition of an index
Syntax:
#把索引重新命名
ALTER INDEX [ IF EXISTS ] name RENAME TO new_name
#把索引遷移表空間
ALTER INDEX [ IF EXISTS ] name SET TABLESPACE tablespace_name
#把索引重設置填充因子
ALTER INDEX [ IF EXISTS ] name SET ( storage_parameter = value [, ... ] )
#把索引的填充因子設置為默認值
ALTER INDEX [ IF EXISTS ] name RESET ( storage_parameter [, ... ] )
#把表空間TSP1中索引遷移到新表空間
ALTER INDEX ALL IN TABLESPACE name [ OWNED BY role_name [, ... ] ]
    SET TABLESPACE new_tablespace [ NOWAIT ]

4.3 刪除索引

刪除索引語法

lottu=# \h drop index
Command:     DROP INDEX
Description: remove an index
Syntax:
DROP INDEX [ CONCURRENTLY ] [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

5. 索引的維護

索引能帶來加快對表中記錄的查詢，排序，以及唯一約束的作用。索引也是有代價

  • 索引需要增加數據庫的存儲空間。
  • 在表記錄執行插入，更新，刪除操作。索引也要更新。

5.1 查看索引的大小

select pg_size_pretty(pg_relation_size(‘ind_t_id‘));

5.2 索引的利用率

--通過pg_stat_user_indexes.idx_scan可檢查利用索引進行掃描的次數；這樣可以確認那些索引可以清理掉。
select idx_scan from pg_stat_user_indexes where indexrelname = ‘ind_t_id‘;

5.3 索引的重建

--如果一個表經過頻繁更新之後，索引性能不好；需要重建索引。
lottu=# select pg_size_pretty(pg_relation_size(‘ind_t_id_1‘)); 
 pg_size_pretty 
----------------
 2200 kB
(1 row)

lottu=# delete from t where id > 1000;
DELETE 99000

lottu=# analyze t;
ANALYZE
lottu=# select pg_size_pretty(pg_relation_size(‘ind_t_id_1‘)); 
 pg_size_pretty 
----------------
 2200 kB
 
lottu=# insert into t select generate_series(2000,100000),‘lottu‘;
INSERT 0 98001

lottu=# select pg_size_pretty(pg_relation_size(‘ind_t_id_1‘)); 
 pg_size_pretty 
----------------
 4336 kB
(1 row)

lottu=# vacuum full t;
VACUUM

lottu=# select pg_size_pretty(pg_relation_size(‘ind_t_id_1‘)); 
 pg_size_pretty 
----------------
 2176 kB
 
重建方法： 
1. reindex：reindex不支持並行重建【CONCURRENTLY】;索引會鎖表；會進行阻塞。
2. vacuum full; 對表進行重構；索引也會重建；同樣也會鎖表。
3. 創建一個新索引(索引名不同)；再刪除舊索引。

淺談PostgreSQL的索引

相關推薦

淺談PostgreSQL的索引

all b- command 唯一索引 rom hang ocs erb 5.6 1. 索引的特性 1.1 加快條件的檢索的特性 當表數據量越來越大時查詢速度會下降，在表的條件字段上使用索引，快速定位到可能滿足條件的記錄，不需要遍歷所有記錄。 create table t

淺談資料庫索引的使用規則

對各位兄弟的建議：有些論壇或者帖子，若果感覺自己要掌握這些知識點，最好試試，不要隨便轉帖，讓錯誤的東西誤導更多的人！！！淺談資料庫索引主要包括如下幾個方面索引原則所謂的最左原則(重點) 索引失效的條件1、使用不等於操作符(<>, !=)；下面這種情況，即使在列de

淺談MySQL索引背後的資料結構及演算法

摘要 本文以MySQL資料庫為研究物件，討論與資料庫索引相關的一些話題。特別需要說明的是，MySQL支援諸多儲存引擎，而各種儲存引擎對索引的支援也各不相同，因此MySQL資料庫支援多種索引型別，如BTree索引，雜湊索引，全文索引等等。為了避免混亂，本文將只關注

淺談PostgreSQL使用者許可權

問題 　　經常在PG群裡看到有人在問“為什麼我對錶賦予了許可權；但是還是不能訪問表” 解析 　　若你看懂德哥這篇文章PostgreSQL邏輯結構和許可權體系介紹；上面對你就不是困擾你的問題 　　解決這個問題很簡單；在解決之前；我們要先了解PostgreSQL的邏輯結構、以及與使用者之間

淺談sql索引

# 索引是什麼 假如你手上有一個你公司的客戶表，老闆說找什麼客戶你就得幫他找出來。 客戶不多的時候，你拿著手指一行一行滑，費不了多少時間就能找到。 後來公司做大了，客戶越來越多，好幾頁的客戶，你發現，一行一行滑真的好累啊，最主要找慢了還得挨老闆叼。 他媽的，吃力不討好。 那咋辦？ 我相信這麼聰明的你

淺談SQL優化入門：3、利用索引

其它 工作 書籍 htm color 之前 index mage 即使 0、寫在前面的話關於索引的內容本來是想寫的，大概收集了下資料，發現並沒有想象中的簡單，又不想總結了，糾結了一下，決定就大概寫點淺顯的，好吧，就是懶，先挖個淺坑，以後再挖深一點。最基本的使用很簡單，直接就

淺談MySQL的B樹索引與索引優化

成本 情況 但是 數據行 eat bst tree bfs 優化 前言 MySQL的MyISAM、InnoDB引擎默認均使用B+樹索引（查詢時都顯示為“BTREE”），本文討論兩個問題： 為什麽MySQL等主流數據庫選擇B+樹的索引結構？ 如何基於索引結構，理解常見的MyS

淺談索引系列之本地索引與全域性索引

分割槽表按照型別可以分為範圍分割槽(Range)、列表分割槽(List)以及雜湊分割槽(Hash),表被分割槽後，其對應的索引也會與普通表的索引有所不同。 基本概念        對於分割槽表上的索引可以分為兩類：本地索引和全域性索引。其中全域性索引又

從MySQL Bug#67718淺談B+樹索引的分裂優化（轉）

原文連結：http://hedengcheng.com/?p=525   問題背景 今天，看到Twitter的DBA團隊釋出了其最新的MySQL分支：Changes in Twitter MySQL 5.5.28.t9，此分支最重要的一個改進，就是修復了MySQL 的Bug #67718：In

淺談sql server聚集索引與非聚集索引

今天同事的服務程式在執行批量插入資料操作時，會超時失敗，程式碼debug了幾遍一點問題都沒有，SQL單條插入也可以正常錄入資料，除錯了一上午還是很迷茫，場面一度很尷尬，最後還是發現了問題的根本，原來是另一個同事為了提升查詢效率濫用了索引在搞鬼，沒有合理的運用索引使每次新增和修改資料時效率極低，大批量插入和修改

淺談索引對資料庫效能的影響

大家都知道，對於資料庫來說，常見的瓶頸問題多是CPU or IO過高造成的，如果能夠有效的解決這兩個問題，那麼的確是功德可見的，那麼業界現在也有很多的方式在達到這樣的目的，比如：在DB層的前面加一箇中間層：例如：memcached。做DB的資料快取，然後從一定程度上減少熱

淺談B樹，B+樹，B*樹及分析MySQL的索引

樹的基本概念 根：樹的頂端結點 兄弟：具有同一個雙親(Parent)的孩子(Child)之間互稱為兄弟(Sibling)。 祖先：結點的祖先(Ancestor)是從根（Root）到該結點所經分支(Branch)上的所有結點。 葉子（終端結點）：沒有孩子的結點(也就是度為0的結點)稱為

淺談android中手機聯絡人字母索引表的實現

實際上字母索引表的效果，可以說在現在的眾多APP中使用的非常流行，比如支付寶，微信中的聯絡人，還有購物，買票的APP中選擇全國城市，切換城市的時候，這時候的城市也就是按照一個字母索引的順序來顯示，看起來是很方便的．其實這種字母索引表的效果最開始是出現在微信的聯絡人中．因為覺

淺談mysql的鎖和索引之間莫大的聯絡

  在平時我們用mysql的鎖時，一般剛接觸資料庫是很少考慮鎖的效率，一般只求到達防止併發的目的就可以了，但是隨著資料量的增大我們就會發現有很多sql我們已經寫的非常優化了，但是有時候還是很慢，很難找到原因，這時候我們就應該考慮一下是不是mysql的鎖在導致的，（當然可能的

淺談數據庫索引的結構設計與優化

子句 項目 結果 使用 enter tex 設有 簡單的 相同 淺談數據庫索引的結構設計與優化 一. 了解數據庫索引的必要性 　　對於稍微數據量大一點的表，如果不適用索引，那麽性能效率都會很低；如果繞開了索引，直接進行分區分表，數據庫集群讀寫分離來解決性能問題的

淺談聚簇索引和非聚簇索引的區別

聚簇索引：將資料儲存與索引放到了一塊，索引結構的葉子節點儲存了行資料 非聚簇索引：將資料與索引分開儲存，索引結構的葉子節點指向了

淺談計算機領域及職業憧憬

計算機科學 軟件工程師 計算機行業 雖然自己的專業是計算機，可是慚愧的說其實對這個行業的了解並不是很多，大多時候是通過網絡或者新聞才了解到的。據我所知，現在計算機行業是非常流行的行業，當然競爭也是十分激烈，信息化的時代我們的生活都離不開與計算機有關的東西，比如上學坐公共汽車，需要刷卡，這就是

Java學習筆記——淺談數據結構與Java集合框架（第一篇、List）

技術分享 emp 鏈表 adc 下標 -c nod nal integer 橫看成嶺側成峰，遠近高低各不同。不識廬山真面目，只緣身在此山中。 　　　　　　　　　　　　　　——蘇軾 這一塊兒學的是雲裏霧裏，咱們先從簡單的入手。逐漸的撥開迷霧見太陽。本次先做List集合的三

淺談HTTP請求與響應

tcp 方法 刪除 請求 連接 客戶機 cin tex 文件 HTTP協議用於客戶端和服務器之間的通信，請求訪問的一段是客戶端，提供資源響應的一段是服務器端。 HTTP通信是采用請求應答的方式來進行的，客戶端發出請求，服務器響應。如果沒有客戶端的請求，服務器端是不進行任

淺談C#解析網頁

多說 .text 了解 light path text load 所有 web 最近做了一個項目，要求獲取各大主流網頁上的關鍵信息，本人以前了解過網頁爬蟲的知識，所以想到了網頁爬蟲了實現功能 第一次嘗試： 采用webclient獲取遠程網頁的內容，然後采用正則表達式進行過濾