PostgreSQL统计信息的几个重要视图

  

1, pg_stat_database   

 <代码> yz=# select * from pg_stat_database;
  -[1]记录——+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  datid | 13156 #数据库的oid
  datname | postgres #数据库名
  numbackends | 0 #访问当前数据库的连接数量
  xact_commit | 2357 #该数据库事务提交总量:和下面的回滚和作为TPS统计
  xact_rollback | 17 #该数据库事务滚总量,如果特别多,需要看业务是否有问题了
  blks_read | 1946 #总磁盘物理读的块数,这里的阅读可能是从缓存中读取,如果很高需要结合blk_read_time看是否真的存在从磁盘读取的情况
  blks_hit | 103625 #从共享缓冲区命中块数
  tup_returned | 1413113 #对于表来说,是全表扫描的行数,对于索引是通过索引返回的索引行数,如果这个值明显大于tup_fetched,说明当前数据库存在大量的全表扫描。查看执行计划,这个是databas全局级别的
  tup_fetched | 36041 #指通过索引返回的行数
  tup_inserted | 104 #插入的行数
  tup_updated | 0 #更新的行数
  tup_deleted | 19 #删除的行数
  冲突| 0 #与恢复冲突取消的查询次数,只会在备机上发生
  temp_files | 0 #产生临时文件的数量,如果这个值很高,需要调大work_mem
  temp_bytes | 0 #临时文件的大小
  死锁| 0 #死锁的数量,如果这个值很大说明业务逻辑有问题
  blk_read_time | 0 #数据库中花费在读取文件的时间,这个值很高说明内存较小,需要频繁从磁盘读入数据文件
  blk_write_time | 0 #数据库中花费在写数据文件的时间,pg中脏页一般写入页面缓存,如果这个值较高,则说明缓存较小,操作系统的缓存需要更积极的写入
  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很高,可以说明数据库有频繁的更新,这个时候需要关注真空相关的指标和长事务,如果没有及时进行垃圾回收,会引起表膨胀;
temp_files较高说明存在很多排的序,散列,或者聚合这种操作,可以增大work_mem减少临时文件的产生,并且同时这些操作的性能也会有较大的提升。

  

2, pg_stat_user_tables   

 <代码> yz=# select * from pg_stat_user_tables;
  -[1]记录- - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  relid | 16440 #表oid
  schemaname |公共#模式名
  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 #热更新的数据行数,这个值与n_tup_upd接近说明更新性能较好,不需要更新索引
  n_live_tup | 655366 #活的行数量
  n_dead_tup | 0 #死记录个数
  n_mod_since_analyze | 6 #上次分析的实际
  last_vacuum | 2019-04-07 00:22:00.955542-07 #上次手动真空的实际
  last_autovacuum | #上次autovacuum的实际
  last_analyze | #上次分析时间
  last_autoanalyze | 2019-04-07 00:26:07.668391-07 #上次自动分析时间
  vacuum_count | 2 #真空次数
  autovacuum_count | 0 #自动真空次数
  analyze_count | 0 #分析次数
  autoanalyze_count | 10 #自动分析次数 
  

通过查询pg_stat_user_tables,可以基本清除哪些表的全表扫描次数较多,表中DML哪种操作多,也可以了解垃圾数据的数量。

  

3, pg_stat_user_indexes   

 <代码> yz=# select * from pg_stat_user_indexes;
  -[1]记录- + - - - - - - - - - - -
  relid | 16447 #相关表的oid
  indexrelid | 16450 #索引的oid
  schemaname |公共#模式名
  relname | t3 #表名
  indexrelname | t3_id_idx #索引名
  idx_scan | 0 #通过索引扫描的次数,如果该值很小,说明该索引很少被用的到,可以考虑删除
  idx_tup_read | 0 #通过任意索引方法返回的索引行数
  idx_tup_fetch | 0 #通过索引方法返回的数据行数 
  

可以知道当前哪些索引频繁使用,哪些是无效索引。无效索引可以删除掉,减少磁盘空间的使用和提升插入、删除、更新的性能。

PostgreSQL统计信息的几个重要视图