连接表时未使用索引

Question

We have four tables involved:

• lists
• influencer_lists (join table)

This is the query:

SELECT influencer_lists.influencer_id 
FROM influencer_lists
LEFT OUTER JOIN lists ON lists.id = influencer_lists.list_id
WHERE influencer_lists.influencer_id IN (12, 95, 33, 23, 35, 36, 27, 41, 42, 43, 45, 30) 
AND "lists"."user_id" = 1

When doing explain, two things are noticed:

1. No index is being used at some point when looking for influencer_id
2. Index is being used for

EXPLAIN output:

Nested Loop  (cost=0.28..73.59 rows=9 width=4) (actual time=0.031..0.187 rows=4 loops=1)
->  Seq Scan on influencer_lists  (cost=0.00..10.82 rows=9 width=8) (actual time=0.016..0.152 rows=5 loops=1)
Filter: (influencer_id = ANY ('{12,95,33,23,35,36,27,41,42,43,45,30}'::integer[]))
Rows Removed by Filter: 308
->  Index Scan using lists_pkey on lists  (cost=0.28..6.96 rows=1 width=4) (actual time=0.005..0.005 rows=1 loops=5)
Index Cond: (id = influencer_lists.list_id)
Filter: (user_id = 1)
Rows Removed by Filter: 0
Planning time: 0.621 ms
Execution time: 0.235 ms

We want to improve the query time. How can we do it?

Thanks.

Answer 1

The first thing i would suggest is to update the stats for the tables involved. If you are experience performance this is a great first start.

 ANALYZE [tablename] ;

Secondly because there is an index on this column it does not mean it will always be used. The range of values in the 'IN' clause may consist of too many id's to warrant using the index. You could try individual id = [value]

Answer 2

If the SELECT returns more than approximately 5-10%(depends on configuration settings and the storage of the data as well. It's not a hard number) of all rows in the table, a sequential scan is much faster than an index scan.

Index scan requires several IO operations for each row (look up the row in the index, then retrieve the row from the heap). Sequential scan only requires a single IO for each row - or even less because a block (page) on the disk contains more than one row, so more than one row can be fetched with a single IO operation.