亞馬遜EC2 m1.large上的Postgres 9.1有時候查詢速度非常慢

我已經看到這個查詢對於各種personid和不同的類型需要少於10毫秒，我也看到它花費了16分鐘。到底是怎麼回事？亞馬遜EC2 m1.large上的Postgres 9.1有時候查詢速度非常慢

Column |  Type  |      Modifiers 
--------------+------------------+-------------------------------------------------------- 
id   | bigint   | not null default nextval('record_seq'::regclass) 
type   | integer   | not null 
personid  | integer   | 
reporttime | bigint   | not null 
totalreading | double precision | not null 
delta  | double precision | not null 

Indexes: 
    "record_pkey" PRIMARY KEY, btree (id) 
    "record_personid_idx" btree (personid) 
    "record_type_idx" btree (type) 
    "record_reporttime_idx" btree (reporttime) CLUSTER

這是對有時非常慢的查詢的解釋分析。

explain analyze SELECT ID, TYPE, REPORTTIME, TOTALREADING, DELTA, PERSONID FROM RECORD WHERE PERSONID=1103 AND TYPE=405 AND REPORTTIME <= 1332447354000 ORDER BY REPORTTIME DESC LIMIT 1; 

Limit (cost=0.00..327.93 rows=1 width=52) (actual time=239749.274..239749.274 rows=0 loops=1) 
    -> Index Scan Backward using record_reporttime_idx on record (cost=0.00..1196290.82 rows=3648 width=52) (actual time=239749.251..239749.251 rows=0 loops=1) 
     Index Cond: (reporttime <= 1332447354000::bigint) 
     Filter: ((personid = 1103) AND (type = 405)) 
Total runtime: 239749.409 ms

在大致有10〜20種，有2所使用最頻繁的，405幾乎沒有經常使用。

select count(*) from record; 
    count 
---------- 
30420232 

SELECT COUNT(*) FROM record WHERE PERSONID=1103 AND TYPE=405; 
    count 
------- 
    58

來源

2012-03-23 xordon

因爲您正在搜索最後的reporttime值，因此計劃人員認爲向後搜索時有意義。

它可能會做某些/大部分時間，但有時候您必須經過很長時間才能找到正確的組合（personid，type）。

如果您通常在（personid，type）上進行搜索，則可以在兩個或者甚至全部三個列上嘗試組合索引。三列的排序以及您是否需要保留其他索引將取決於您的總查詢組合。

來源

2012-03-23 09:20:01

問題是，當沒有匹配該查詢的記錄時，postgres將不得不掃描整個表。如果有一些數據具有相對較新的時間戳，查詢將很快返回。 – xordon 2012-07-17 21:08:29

亞馬遜EC2 m1.large上的Postgres 9.1有時候查詢速度非常慢

回答

相關問題