Question

我已经看到这个查询的各种人物和不同的类型需要不到10毫秒，我也看到它需要16分钟。发生了什么事？

    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

Answer 1

因为您正在搜索某个目标之前的最后一个报告时间值，所以计划程序认为向后搜索是有意义的。

它可能会在一些/大部分时间内完成，但偶尔您需要很长一段时间才能找到（personid，type）的正确组合。

如果您通常搜索（personid，type），请在两个列上尝试组合索引，或者甚至可以尝试所有三列。三列的排序以及是否需要保留其他索引将取决于您的总查询组合。

Amazon EC2上的Postgres 9.1 m1.large有时查询速度非常慢

1 个答案: