多列顺序通过杀死postgresql性能，有什么办法解决？

Question

我有一个非常简单的查询，我在一个大表（500k行）上运行以分页结果。

最初我使用的是这个查询，它确实非常快：

 select * from deck 
    order by
        deck.sas_rating desc    
    limit 10

其说明分析显示出0.2ms的执行时间。 凉。

但是sas_rating列具有重复的整数值，当我分页浏览结果时（使用其他页面的偏移量），我意识到我正在获得重复的结果。 没问题，将主键添加为辅助顺序。 但是性能很差 。

 select * from deck 
    order by
        deck.sas_rating desc,
        deck.id asc     
    limit 10

花费685ms并进行以下分析：

Limit  (cost=164593.15..164593.17 rows=10 width=1496) (actual time=685.138..685.139 rows=10 loops=1)
  ->  Sort  (cost=164593.15..165866.51 rows=509343 width=1496) (actual time=685.137..685.137 rows=10 loops=1)
        Sort Key: sas_rating DESC, id
        Sort Method: top-N heapsort  Memory: 59kB
        ->  Seq Scan on deck  (cost=0.00..153586.43 rows=509343 width=1496) (actual time=0.009..593.444 rows=509355 loops=1)
Planning time: 0.143 ms
Execution time: 685.171 ms

在我较弱的生产服务器上，情况甚至更糟。 我的搜索时间从125毫秒变为35秒钟！

我尝试添加多列索引，但这并没有提高性能。 在使用limit + offset时，有什么方法可以防止重复的结果而不破坏查询的性能吗？

Answer 1

我相信您可能错误地添加了多列索引-例如，您使用sas_rating, id而不是sas_rating desc, id ，因为只能使用后者。

sas_rating上的索引仅可用于sas_rating desc排序，因为数据库可以向后进行排序。 多列索引不是这种情况-您必须像在排序中一样保留列的升序/降序。