1

我有一个相当大的表，有近 100 万行，其中一些查询需要很长时间（超过一分钟）。

这是一个让我特别难过的...

EXPLAIN ANALYZE SELECT "apps".* FROM "apps" WHERE "apps"."kind" = 'software' ORDER BY itunes_release_date DESC, rating_count DESC LIMIT 12;
                                                           QUERY PLAN                                                            
---------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=153823.03..153823.03 rows=12 width=2091) (actual time=162681.166..162681.194 rows=12 loops=1)
   ->  Sort  (cost=153823.03..154234.66 rows=823260 width=2091) (actual time=162681.159..162681.169 rows=12 loops=1)
         Sort Key: itunes_release_date, rating_count
         Sort Method: top-N heapsort  Memory: 48kB
         ->  Seq Scan on apps  (cost=0.00..150048.41 rows=823260 width=2091) (actual time=0.718..161561.149 rows=808554 loops=1)
               Filter: (kind = 'software'::text)
 Total runtime: 162682.143 ms
(7 rows)

那么，我将如何优化呢？PG 版本是 9.2.4，FWIW。

kind和上已有索引kind, itunes_release_date。

4

3 回答 3

3

看起来您缺少索引，例如 on (kind, itunes_release_date desc, rating_count desc)。

于 2013-06-03T14:13:01.740 回答
0

apps桌子有多大？你至少有这么多内存分配给 postgres 吗？如果每次都必须从磁盘读取，查询速度会慢很多。

可能有帮助的另一件事是将表聚集在“应用程序”列上。这可能会加快磁盘访问速度，因为所有software行都将按顺序存储在磁盘上。

于 2013-06-03T14:20:27.363 回答
0

加快此查询的唯一方法是在(itunes_release_date, rating_count). 它将允许 Postgres 直接从索引中选择前 N 行。

于 2013-06-03T14:20:43.780 回答