通过pg_stat_database我们就可以概解数据库的历史情况,如看到tup_returned值远于
tup_fetched,说明数据库历史执的sql很多都是全表扫描,说明存在很多没有索引的sql,这时候可
以结合pg_stat_statments来查找慢sql,也可以通过pg_stat_user_tables找到全表扫描次数和数最多
的表。通过看到tup_updated很说明数据库有很频繁的新,这个时候就需要关注下vacuum相关
的指标和事务,如果没有及时进垃圾回收会造成数据膨胀的较厉害。如果temp_files较的话说
明存在很多的排序,hash,或者聚合这种操作,可以通过增work_mem减少临时件的产,并且
同时这些操作的性能也会有较的提升。
3.pg_stat_user_tables关键指标
通过查询pg_stat_user_tables,可以基本清楚哪些表的全表扫描的次数较多,表中是插还是新,删
除较多。也可以解当前表中垃圾数据的数。
4.pg_stat_user_indexes关键指标
blk_read_time | 0 #数据库中花费在读取件的时间,这个值较说
明内存较,需要频繁的从磁盘中读数据件
blk_write_time | 0 #数据库中花费在写数据件的时间,pg中脏
般都写page cache,如果这个值较,说明page cache较,操作系统的page cache需要积极的
写。
stats_reset | 2019-04-09 14:06:53.416473+08 #统计信息重置的时间
relid | 16390 #表的oid
schemaname | public #模式名称
relname | pgbench_accounts #表名
seq_scan | 0 #这个表进全表扫描的次数
seq_tup_read | 0 #全表扫描的数据数,如果这个值很说明
对这个表进sql很有可能都是全表扫描,需要结合具体的执计划来看
idx_scan | 29606482 #索引扫描的次数
idx_tup_fetch | 29606482 #通过索引扫描返回的数
n_tup_ins | 0 #插的数据数
n_tup_upd | 14803241 #新的数据数
n_tup_del | 0 #删除的数据数
n_tup_hot_upd | 14638544 #hot update的数据数,这个值与
n_tup_upd越接近说明update的性能较好,新数据时会新索引。
n_live_tup | 100012319 #活着的数
n_dead_tup | 2403437 #死亡的数
n_mod_since_analyze | 0 #上次analyze的时间
last_vacuum | #上次动vacuum的时间
last_autovacuum | #上次autovacuum的时间
last_analyze | #上次analyze的时间
last_autoanalyze | 2019-04-09 14:12:30.402387+08 #上次动analyze的时间
vacuum_count | 0 #vacuum的次数
autovacuum_count | 0 #autovacuum的次数
analyze_count | 0 #analyze的次数
autoanalyze_count | 1 #动analyze的次数
评论