2010-07-23 62 views
67

是否有工具或方法来分析Postgres,并确定应该创建哪些缺失的索引以及哪些未使用的索引应该被删除?我对SQLServer的“profiler”工具有一点经验,但我不知道Postgres中包含了类似的工具。PostgreSQL索引使用分析

+0

原来是这样。有一段时间没有看过这个。更新了我接受的答案。 – Cerin 2015-01-08 15:21:52

回答

128

我喜欢寻找失踪指标:

SELECT schemaname, relname, seq_scan-idx_scan AS too_much_seq, case when seq_scan-idx_scan>0 THEN 'Missing Index?' ELSE 'OK' END, pg_relation_size(format('%I.%I', schemaname, relname)::regclass) AS rel_size, seq_scan, idx_scan 
FROM pg_stat_user_tables 
WHERE pg_relation_size(format('%I.%I', schemaname, relname)::regclass)>80000 ORDER BY too_much_seq DESC; 

此检查是否有更多的顺序扫描,然后索引扫描。如果表格很小,它会被忽略,因为Postgres似乎更喜欢它们的顺序扫描。

上面的查询确实显示缺少索引。

下一步将检测缺失的组合索引。我想这不容易,但可行。也许分析缓慢的查询...我听到pg_stat_statements可以帮助...

+7

要使用带引号的标识符进行此项工作,请将查询更改为: 'SELECT relname,seq_scan-idx_scan AS too_much_seq,seq_scan-idx_scan> 0时的情况那么'缺少索引?' ELSE 'OK' END, pg_relation_size(RELID :: regclass的)AS rel_size,seq_scan,idx_scan FROM pg_stat_sys_tables和pg_stat_all_tables WHERE SCHEMANAME = '公共' AND pg_relation_size(RELID :: regclass的)> 80000 ORDER BY too_much_seq DESC;' – 2016-01-20 16:30:26

+7

的输出这个查询应该被解释为使答案更有帮助 – cen 2017-01-31 11:25:55

+0

在@cen的时候,当'too_much_seq'是积极的和大的,你应该关心。 – mountainclimber 2017-09-27 18:11:09

-1

这应有助于:Pratical Query Analysis

+1

PQA的最近更新已有几年的历史。它有一个不被pgFouine支持的功能吗? – guettli 2012-10-10 10:55:04

8

在确定失踪指标接近....都能跟得上。但是有一些计划在未来的版本中使这更容易,比如伪索引和机器可读的EXPLAIN。

目前,您需要EXPLAIN ANALYZE性能较差的查询,然后手动确定最佳路线。一些日志分析器如pgFouine可以帮助确定查询。

至于未使用的指标,可以使用类似以下内容,以帮助确定他们:

select * from pg_stat_all_indexes where schemaname <> 'pg_catalog'; 

这将有助于识别元组读取,扫描,牵强。

+0

Frank Heikens还指出了其他地方查询当前索引使用情况的好地方。 – rfusca 2010-07-23 14:22:40

3

有多个脚本链接可帮助您在PostgreSQL wiki处找到未使用的索引。基本技术是查看pg_stat_user_indexes并查找其中idx_scan(该索引用于回答查询的次数)为零或至少非常低的次数。如果应用程序发生了变化,而且以前使用的索引可能不是现在,则有时必须运行pg_stat_reset()才能将所有统计数据恢复为0,然后收集新数据;你可以保存当前所有值并计算增量,而不是计算出来。

目前还没有好的工具可用于建议缺失的索引。一种方法是记录正在运行的查询,并分析哪些查询需要很长时间才能使用查询日志分析工具(如pgFouine或pqa)运行。有关更多信息,请参阅“Logging Difficult Queries”。

另一种方法是查看pg_stat_user_tables并查找对其有大量顺序扫描的表,其中seq_tup_fetch很大。当使用索引时,idx_fetch_tup计数会增加。当表格索引不足以回答对它的查询时,这可能会提示您。

其实搞清楚应该索引哪些列?这通常会再次导致查询日志分析。

0

PoWA似乎是PostgreSQL 9.4+的一个有趣的工具。它收集统计数据,将它们可视化,并建议索引。它使用pg_stat_statements扩展名。

PoWA是PostgreSQL工作负载分析器,它收集性能统计信息并提供实时图表来帮助监视和调整PostgreSQL服务器。它类似于Oracle AWR或SQL Server MDW。

5

分析PostgreSQL的另一个新的有趣的工具是PgHero。它更侧重于调整数据库并进行大量分析和建议。

screenshot

1

您可以使用以下查询来查找索引使用情况和索引的大小:

Reference is taken from this blog.

SELECT 
    pt.tablename AS TableName 
    ,t.indexname AS IndexName 
    ,pc.reltuples AS TotalRows 
    ,pg_size_pretty(pg_relation_size(quote_ident(pt.tablename)::text)) AS TableSize 
    ,pg_size_pretty(pg_relation_size(quote_ident(t.indexrelname)::text)) AS IndexSize 
    ,t.idx_scan AS TotalNumberOfScan 
    ,t.idx_tup_read AS TotalTupleRead 
    ,t.idx_tup_fetch AS TotalTupleFetched 
FROM pg_tables AS pt 
LEFT OUTER JOIN pg_class AS pc 
    ON pt.tablename=pc.relname 
LEFT OUTER JOIN 
( 
    SELECT 
     pc.relname AS TableName 
     ,pc2.relname AS IndexName 
     ,psai.idx_scan 
     ,psai.idx_tup_read 
     ,psai.idx_tup_fetch 
     ,psai.indexrelname 
    FROM pg_index AS pi 
    JOIN pg_class AS pc 
     ON pc.oid = pi.indrelid 
    JOIN pg_class AS pc2 
     ON pc2.oid = pi.indexrelid 
    JOIN pg_stat_all_indexes AS psai 
     ON pi.indexrelid = psai.indexrelid 
)AS T 
    ON pt.tablename = T.TableName 
WHERE pt.schemaname='public' 
ORDER BY 1;