慢sql選擇與索引postgres

我有一個生產數據庫複製到另一個主機使用londist。該表看起來像慢sql選擇與索引postgres

# \d+ usermessage 
       Table "public.usermessage" 
    Column  |  Type  | Modifiers | Description 
-------------------+-------------------+-----------+------------- 
id    | bigint   | not null | 
subject   | character varying |   | 
message   | character varying |   | 
read    | boolean   |   | 
timestamp   | bigint   |   | 
owner    | bigint   |   | 
sender   | bigint   |   | 
recipient   | bigint   |   | 
dao_created  | bigint   |   | 
dao_updated  | bigint   |   | 
type    | integer   |   | 
replymessageid | character varying |   | 
originalmessageid | character varying |   | 
replied   | boolean   |   | 
mheader   | boolean   |   | 
mbody    | boolean   |   | 
Indexes: 
"usermessage_pkey" PRIMARY KEY, btree (id) 
"usermessage_owner_key" btree (owner) 
"usermessage_recipient_key" btree (recipient) 
"usermessage_timestamp_key" btree ("timestamp") 
"usermessage_type_key" btree (type) 
Has OIDs: no

如果複製的數據庫上執行，選擇快如預期，如果生產主機上執行它的可怕緩慢。爲了讓事情變得更奇怪，並非所有時間戳都很慢，其中一些主機上的一些速度很快。生產主機後面的文件系統和存儲很好，而且使用量不大。有任何想法嗎？

replication# explain analyse SELECT COUNT(id) FROM usermessage WHERE owner = 1234567 AND timestamp > 1362077127010; 
                   QUERY PLAN 
---------------------------------------------------------------------------------------------------------------------------------------------------- 
Aggregate (cost=263.37..263.38 rows=1 width=8) (actual time=0.059..0.060 rows=1 loops=1) 
    -> Bitmap Heap Scan on usermessage (cost=259.35..263.36 rows=1 width=8) (actual time=0.055..0.055 rows=0 loops=1) 
     Recheck Cond: ((owner = 1234567) AND ("timestamp" > 1362077127010::bigint)) 
     -> BitmapAnd (cost=259.35..259.35 rows=1 width=0) (actual time=0.054..0.054 rows=0 loops=1) 
       -> Bitmap Index Scan on usermessage_owner_key (cost=0.00..19.27 rows=241 width=0) (actual time=0.032..0.032 rows=33 loops=1) 
        Index Cond: (owner = 1234567) 
       -> Bitmap Index Scan on usermessage_timestamp_key (cost=0.00..239.82 rows=12048 width=0) (actual time=0.013..0.013 rows=0 loops=1) 
        Index Cond: ("timestamp" > 1362077127010::bigint) 
Total runtime: 0.103 ms 
(9 rows) 

production# explain analyse SELECT COUNT(id) FROM usermessage WHERE owner = 1234567 AND timestamp > 1362077127010; 
                     QUERY PLAN 
------------------------------------------------------------------------------------------------------------------------------------------------------------------ 
Aggregate (cost=267.39..267.40 rows=1 width=8) (actual time=47536.590..47536.590 rows=1 loops=1) 
    -> Bitmap Heap Scan on usermessage (cost=263.37..267.38 rows=1 width=8) (actual time=47532.520..47536.579 rows=3 loops=1) 
     Recheck Cond: ((owner = 1234567) AND ("timestamp" > 1362077127010::bigint)) 
     -> BitmapAnd (cost=263.37..263.37 rows=1 width=0) (actual time=47532.334..47532.334 rows=0 loops=1) 
       -> Bitmap Index Scan on usermessage_owner_key (cost=0.00..21.90 rows=168 width=0) (actual time=0.123..0.123 rows=46 loops=1) 
        Index Cond: (owner = 1234567) 
       -> Bitmap Index Scan on usermessage_timestamp_key (cost=0.00..241.22 rows=12209 width=0) (actual time=47530.255..47530.255 rows=5255617 loops=1) 
        Index Cond: ("timestamp" > 1362077127010::bigint) 
Total runtime: 47536.668 ms 
(9 rows)

來源

2013-03-07 frank

您是否嘗試過在生產數據庫上運行分析？ – 2013-03-07 16:07:55

嘗試運行SELECT COUNT（timestamp）FROM usermessage WHERE owner = 1234567兩個 – 2013-03-07 16:14:11

如果你還沒有運行真空，你應該先嚐試一下。 – PJLopez 2013-03-07 16:01:47

我與PostgreSQL的比MySQL但

不太熟悉的（實際時間= 0.013..0.013行= 0的循環= 1）

和

（實際時間= 47530.255。 .47530.255 rows = 5255617 loops = 1）

給我建議你的生產數據庫有更多的數據，因爲行數大不相同。

來源

2013-03-07 15:58:37

慢sql選擇與索引postgres

回答

相關問題