Django的慢速查詢性能提高

Question

我使用Django與Postgres的，並具有下列表格：

class Person(models.Model): 
    person_id=models.IntegerField(primary_key=True) 
    name = models.CharField(max_length=500, blank=True) 
    description = models.ManyToManyField('descriptions.Description', through='DescriptionPersonUser') 

class DescriptionPersonUser(models.Model): 
    person = models.ForeignKey(Person) 
    description = models.ForeignKey('descriptions.Description') 
    user = models.ForeignKey(User) 

    class Meta: 
     managed = True 
     unique_together = ('person', 'description', 'user') 

class Description(models.Model): 
    description_id=models.AutoField (primary_key=True) 
    description_word=models.CharField(max_length=50, blank=True, unique=True) 

class AuthUser(models.Model): 
    id = models.IntegerField(primary_key=True) # AutoField? 
    ... 
    username = models.CharField(unique=True, max_length=30) 

Person表已超過1.5 MIO行和其他表有每次不超過100行。據我瞭解，執行「正常」查詢應該仍然合理。我想通過來自DescriptionPersonUser表的count註釋計數來訂購Person表。

person_list = Person.objects.annotate(count=Count('descriptionpersonuser')).order_by('-count')[:10] 

此查詢需要cca 50000毫秒加載。比我試圖執行它在原始的SQL和改進了很多cca 1900毫秒。

person_list= Person.objects.raw('SELECT "person"."person_id", COUNT("persons_descriptionpersonuser"."id") AS "count" FROM "person" LEFT OUTER JOIN "persons_descriptionpersonuser" ON ("person"."person_id" = "persons_descriptionspersonuser"."person_id") GROUP BY "person"."person_id" ORDER BY "count" DESC, "person"."person_id" ASC LIMIT 10'), 

我還創建了persons_descriptionpersonuser指數：

CREATE INDEX index_descriptionpersonuser ON persons_descriptionpersonuser (person_id, description_id, id); 

所以我的問題是：

1. 仍然有餘量，以加快查詢？或者是1900毫秒1 + mio行查詢體面？
2. 由於我看不到查詢速度與創建的索引有什麼區別，我如何檢查索引是否工作或者是否影響查詢？

編輯（如每Tomasz Jakub Rup建議添加EXPLAIN分析檢索結果）：

而不index_descriptionpersonuser：

Limit (cost=138185.30..138185.33 rows=10 width=8) (actual time=2470.974..2470.976 rows=10 loops=1) 
    -> Sort (cost=138185.30..142177.82 rows=1597006 width=8) (actual time=2470.973..2470.975 rows=10 loops=1) 
     Sort Key: (count(persons_descriptionpersonuser.id)), person.person_id 
     Sort Method: top-N heapsort Memory: 25kB 
     -> GroupAggregate (cost=0.56..103674.58 rows=1597006 width=8) (actual time=0.402..1945.107 rows=1597006 loops=1) 
       Group Key: person.person_id 
       -> Merge Left Join (cost=0.56..79719.49 rows=1597006 width=8) (actual time=0.378..1014.179 rows=1597016 loops=1) 
        Merge Cond: (person.person_id = persons_descriptionpersonuse.person_id) 
        -> Index Only Scan using person_pkey on person (cost=0.43..75718.86 rows=1597006 width=4) (actual time=0.359..610.272 rows=1597006 loops=1) 
          Heap Fetches: 235898 
        -> Index Scan using persons_descriptionpersonuse_person_id on persons_descriptionpersonuser (cost=0.14..12.42 rows=19 width=8) (actual time=0.014..0.025 rows=20 loops=1) 
Planning time: 17.879 ms 
Execution time: 2472.821 ms 
(13 rows) 

與index_descriptionpersonuser：

Limit (cost=138185.55..138185.58 rows=10 width=8) (actual time=2341.349..2341.352 rows=10 loops=1) 
    -> Sort (cost=138185.55..142178.07 rows=1597006 width=8) (actual time=2341.325..2341.325 rows=10 loops=1) 
     Sort Key: (count(persons_descriptionpersonuser.id)), person.person_id 
     Sort Method: top-N heapsort Memory: 25kB 
     -> GroupAggregate (cost=0.56..103674.83 rows=1597006 width=8) (actual time=0.106..1819.330 rows=1597006 loops=1) 
       Group Key: person.person_id 
       -> Merge Left Join (cost=0.56..79719.74 rows=1597006 width=8) (actual time=0.092..877.874 rows=1597016 loops=1) 
        Merge Cond: (person.person_id = persons_descriptionpersonuser.person_id) 
        -> Index Only Scan using person_pkey on person (cost=0.43..75718.86 rows=1597006 width=4) (actual time=0.023..473.046 rows=1597006 loops=1) 
          Heap Fetches: 235898 
        -> Index Only Scan using index_descriptionpersonuser on persons_descriptionpersonuser (cost=0.14..12.44 rows=20 width=8) (actual time=0.059..0.085 rows=20 loops=1) 
          Heap Fetches: 20 
Planning time: 0.715 ms 
Execution time: 2343.815 ms 
(14 rows) 

爲Tomasz Jakub Rup現在所建議的優化的SQL查詢需要cca 40毫秒。下面是結果：

Limit (cost=1.50..1.52 rows=8 width=8) (actual time=0.061..0.064 rows=10 loops=1) 
    -> Sort (cost=1.50..1.52 rows=8 width=8) (actual time=0.060..0.061 rows=10 loops=1) 
     Sort Key: (count(id)), person_id 
     Sort Method: quicksort Memory: 25kB 
     -> HashAggregate (cost=1.30..1.38 rows=8 width=8) (actual time=0.039..0.044 rows=10 loops=1) 
       Group Key: person_id 
       -> Seq Scan on persons_descriptionpersonuser (cost=0.00..1.20 rows=20 width=8) (actual time=0.011..0.018 rows=20 loops=1) 
Planning time: 0.175 ms 
Execution time: 0.129 ms 
(9 rows) 

感謝

Answer 1

回答你的第二個問題：

看

EXPLAIN ANALYZE SELECT "person"."person_... 

查詢的結果。如果您在結果中找到index_descriptionpersonuser，您的查詢使用索引。如果不是，請嘗試創建其他索引。也許只有person_id？

第一個問題：是的，這個查詢可以更快。顯示結果EXPLAIN ANALYZE...然後我們嘗試加快查詢。

注意

原始查詢可能是更快，因爲它們從PostgreSQL的緩存中獲取數據。