PostgreSQL統計信息的幾個重要視圖

一、pg_stat_database

yzs=# select *from pg_stat_database;
-[ RECORD 1 ]--+------------------------------
datid          | 13156                            #數據庫的oid
datname        | postgres                         #數據庫名
numbackends    | 0                                #訪問當前數據庫的鏈接數量
xact_commit    | 2357                             #該數據庫事務提交總量：和下面的rollback和做爲TPS統計
xact_rollback  | 17                               #該數據庫事務rollback總量，若是特別多，須要看業務是否有問題了
blks_read      | 1946                             #總磁盤物理讀的塊數，這裏的read多是從 cache中讀取，若是很高須要結合blk_read_time看是否真的存在從磁盤讀取的狀況
blks_hit       | 103625                           #從shared buffer命中塊數
tup_returned   | 1413113                          #對於表來講，是全表掃描的行數；對於索引是經過索引返回的索引行數，若是這個值明顯大於tup_fetched，說明當前數據庫存在大量的全表掃描。查看執行計劃，這個是databas全局級別的
tup_fetched    | 36041                            #指經過索引返回的行數
tup_inserted   | 104                              #插入的行數
tup_updated    | 0                                #更新的行數
tup_deleted    | 19                               #刪除的行數
conflicts      | 0                                #與恢復衝突取消的查詢次數，只會在備機上發生
temp_files     | 0                                #產生臨時文件的數量，若是這個值很高，須要調大work_mem
temp_bytes     | 0                                #臨時文件的大小
deadlocks      | 0                                #死鎖的數量，若是這個值很大說明業務邏輯有問題
blk_read_time  | 0                                #數據庫中花費在讀取文件的時間，這個值很高說明內存較小，須要頻繁從磁盤讀入數據文件
blk_write_time | 0                                #數據庫中花費在寫數據文件的時間，pg中髒頁通常寫入page cache，若是這個值較高，則說明cache較小，操做系統的cache須要更積極的寫入
stats_reset    | 2019-02-11 23:42:37.526743-08    #統計信息重置的時間

經過pg_stat_database能夠大概瞭解數據庫的歷史狀況。
好比tup_returned值明顯大於tup_fetched，歷史SQL語句不少是全表掃描，存在沒有使用索引的SQL，可結合pg_stat_statments查找慢SQL，也可結合pg_stat_user_table找全表掃描次數和行數最多的表；
經過看tup_updated很高，能夠說明數據庫有頻繁的更新，這個時候須要關注vaccum相關的指標和長事務，若是沒有及時進行垃圾回收，會引發表膨脹；
temp_files較高說明存在不少排序，hash,或者聚合這種操做，能夠增大work_mem減小臨時文件的產生，而且同時這些操做的性能也會有較大的提高。

二、pg_stat_user_tables

yzs=# select *from pg_stat_user_tables;
-[ RECORD 1 ]-------+------------------------------
relid               | 16440        #表oid
schemaname          | public       #模式名
relname             | t1           #表名
seq_scan            | 50           #這個表進行全表掃描的次數
seq_tup_read        | 1867763      #全表掃描的數據行數，若是這個值很大說明操做這個表的SQL語句極可能是全表掃描，須要結合執行計劃分析
idx_scan            |              #索引掃描的次數
idx_tup_fetch       |              #經過索引掃描返回的行數
n_tup_ins           | 1130502      #插入的數據行數
n_tup_upd           | 0            #更新的數據行數
n_tup_del           | 81920        #刪除的數據行數
n_tup_hot_upd       | 0            #hot update的數據行數，這個值與n_tup_upd接近說明更新性能較好，不須要更新索引
n_live_tup          | 655366       #活的行數量
n_dead_tup          | 0            #死記錄個數
n_mod_since_analyze | 6            #上次analyze的實際
last_vacuum         | 2019-04-07 00:22:00.955542-07 #上次手動vacuum的實際
last_autovacuum     |              #上次autovacuum的實際
last_analyze        |              #上次analyze時間
last_autoanalyze    | 2019-04-07 00:26:07.668391-07 #上次自動analyze時間
vacuum_count        | 2            #vacuum次數
autovacuum_count    | 0            #自動vacuum次數
analyze_count       | 0            #analyze次數
autoanalyze_count   | 10           #自動analyze次數

經過查詢pg_stat_user_tables，能夠基本清除哪些表的全表掃描次數較多，表中DML哪一種操做多，也能夠了解垃圾數據的數量。

三、pg_stat_user_indexes

yzs=# select *from pg_stat_user_indexes;
-[ RECORD 1 ]-+----------
relid         | 16447      #相關表的oid
indexrelid    | 16450      #索引的oid
schemaname    | public     #模式名
relname       | t3         #表名
indexrelname  | t3_id_idx  #索引名
idx_scan      | 0          #經過索引掃描的次數，若是該值很小，說明該索引不多被用到，能夠考慮刪除
idx_tup_read  | 0          #經過任意索引方法返回的索引行數
idx_tup_fetch | 0          #經過索引方法返回的數據行數

能夠知道當前哪些索引頻繁使用，哪些是無效索引。無效索引能夠刪除掉，減小磁盤空間的使用和提高insert、delete、update的性能。

四、pg_statio_user_tables

yzs=# select *from pg_statio_user_tables;
-[ RECORD 1 ]---+--------
relid           | 16447    
schemaname      | public
relname         | t3
heap_blks_read  | 1    #從page cache或磁盤讀取表的塊數
heap_blks_hit   | 1    #從shared buffer命中的塊數
idx_blks_read   | 0    #從page cache或磁盤讀取的索引的塊數
idx_blks_hit    | 0    #從shared buffer命中的索引塊數
toast_blks_read |      #從page cache或磁盤讀取的toast表的塊數
toast_blks_hit  |      #在shared buffer中命中toast表的塊數
tidx_blks_read  |      #從page cache或者磁盤中讀入的toast表索引的塊數
tidx_blks_hit   |      #在shared buffer中命中toast表索引的塊數

若是heap_blks_read、idx_blks_read很高，說明shared buffer較小，存在頻繁從磁盤或者page cache讀取到shared buffer中命中toast表的塊數。

五、 pg_stat_bgwriter

yzs=# select *from pg_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed     | 206     #指超過checkpoint_timeout的時間後觸發的檢查點次數
checkpoints_req       | 8       #手動觸發checkpoint或者由於WAL文件數量達到max_wal_size時也會增長，若是這個值大於checkpoints_req說明checkpoint_timeout設置的不合理
checkpoint_write_time | 306582  #從shared buffer 中write到page cache花費的時間
checkpoint_sync_time  | 367     #checkpoint調用fsync將髒數據刷到磁盤花費的時間，若是這個值很長，容易形成IO抖動，須要增長checkpoint_timeout或者checkpoint_completion_target
buffers_checkpoint    | 6671    #經過checkpoint寫入髒塊的數量
buffers_clean         | 0       #經過bgwriter寫入塊的數量
maxwritten_clean      | 0       #bgwriter超過bgwriter_lru_maxpages時中止的次數，若是這個值很高，須要增長bgwriter_lru_maxpages
buffers_backend       | 7953    #經過backend寫入的塊數量
buffers_backend_fsync | 0       #backend須要fsync的次數
buffers_alloc         | 11613   #被分配的緩衝區數量
stats_reset           | 2019-02-11 23:42:35.273758-08

經過這個視圖，能夠判斷checkpoint以及max_wal_size是否合理