Postgres选择慢得多的Seq Scan，而不是Index Scan

Question

首先，请确保计划者已更新统计信息：

my_db=> vacuum analyze;
VACUUM
Time: 1401.958 ms

仅选择时foos.bar_id，在该列上执行“仅索引扫描”即可正常执行查询：

my_db=> EXPLAIN ANALYZE SELECT foos.bar_id FROM foos INNER JOIN bar_ids ON foos.bar_id = bar_ids.id;
 QUERY PLAN                                                                            
 Nested Loop  (cost=0.43..16203.46 rows=353198 width=4) (actual time=0.045..114.746 rows=196205 loops=1)
   ->  Seq Scan on bar_ids  (cost=0.00..16.71 rows=871 width=4) (actual time=0.005..0.195 rows=871 loops=1)
   ->  Index Only Scan using index_foos_on_bar_id on foos  (cost=0.43..14.80 rows=378 width=4) (actual time=0.003..0.055 rows=225 loops=871)
         Index Cond: (bar_id = bar_ids.id)
         Heap Fetches: 0
 Planning time: 0.209 ms
 Execution time: 144.364 ms
(7 rows)

Time: 145.620 ms

但是，添加foos.id会导致查询选择非常慢的Seq扫描：

my_db=> EXPLAIN ANALYZE SELECT foos.id, foos.bar_id FROM foos INNER JOIN bar_ids ON foos.bar_id = bar_ids.id;
 QUERY PLAN                                                            
 Hash Join  (cost=27.60..221339.63 rows=353198 width=8) (actual time=294.091..3341.926 rows=196205 loops=1)
   Hash Cond: (foos.bar_id = bar_ids.id)
   ->  Seq Scan on foos  (cost=0.00..182314.70 rows=7093070 width=8) (actual time=0.004..1855.900 rows=7111807 loops=1)
   ->  Hash  (cost=16.71..16.71 rows=871 width=4) (actual time=0.454..0.454 rows=866 loops=1)
         Buckets: 1024  Batches: 1  Memory Usage: 39kB
         ->  Seq Scan on bar_ids  (cost=0.00..16.71 rows=871 width=4) (actual time=0.002..0.222 rows=871 loops=1)
 Planning time: 0.237 ms
 Execution time: 3371.622 ms
(8 rows)

Time: 3373.150 ms

禁用Seq扫描会强制对同一索引执行索引扫描，这比Seq扫描快一个数量级：

my_db=> set enable_seqscan=false;
SET
Time: 0.801 ms
my_db=> EXPLAIN ANALYZE SELECT foos.id, foos.bar_id FROM foos INNER JOIN bar_ids ON foos.bar_id = bar_ids.id;
 QUERY PLAN                                                                      
 Nested Loop  (cost=10000000000.43..10000439554.99 rows=353198 width=8) (actual time=0.028..171.632 rows=196205 loops=1)
   ->  Seq Scan on bar_ids  (cost=10000000000.00..10000000016.71 rows=871 width=4) (actual time=0.005..0.212 rows=871 loops=1)
   ->  Index Scan using index_foos_on_bar_id on foos  (cost=0.43..500.86 rows=378 width=8) (actual time=0.003..0.118 rows=225 loops=871)
         Index Cond: (bar_id = bar_ids.id)
 Planning time: 0.186 ms
 Execution time: 201.958 ms
(6 rows)

Time: 203.185 ms

其他答案说，计划不佳是由于统计数据不正确。我的统计数据是最新的。是什么赋予了？

bar_ids是一个临时表，该表可能与上次查询（Seq Scan on bar_ids (cost=10000000000.00..10000000016.71）中的疯狂费用估算有关，但显式运行ANALYZE bar_ids不会更改查询计划。

Answer 1

跟进此处对 OP 的评论。

在第一个查询的情况下，当您只选择foos.bar_idexecutor时，可以通过仅索引扫描来实现这一点，这很不错。然而，将另一列（索引未涵盖）添加到选择列表意味着继续使用此索引意味着典型的“双重读取”情况，即我们首先读取索引页然后读取表页以获取剩余的列的值，这意味着相当多的随机 IO 的潜力。

该设置random_page_cost应该相对于seq_page_cost意味着（松散地）随机 IOrandom_page_cost比顺序 IO（给定seq_page_cost=1）昂贵数倍。使用现代驱动器，随机 IO 并不昂贵，因此降低random_page_cost可以使索引扫描更可取。为此找到“最佳”值很棘手，但从 2 左右开始是一个不错的经验法则。

E：我之前没有时间添加这些额外的想法，但它一直困扰着我。如果您因为遇到类似问题而遇到这种情况，请不要只是开始摆弄这个配置。在这种情况下，这似乎是一种富有成效的方法，因为 OP 已经阐明统计数据是新鲜且合理的，索引扫描是可行的，并且计划者对表扫描有更强的偏好，即使这显然更糟（就经验证据）。此配置不是灵丹妙药，如果您遇到的性能问题与此处给出的问题并不真正匹配，那么此解决方案可能不适合您！请考虑其他情况可能需要查询重写或更改其他配置项（尤其是与内存使用和分配相关的那些）。