代码之家  ›  专栏  ›  技术社区  ›  eugene

postgresql,查询运行缓慢

  •  0
  • eugene  · 技术社区  · 4 年前

    这张桌子相当大(与我的其他桌子相比)。 似乎有索引可以帮助对查询中的每一列进行排序。

    如何加快查询速度?

    解释选择“评级历史记录”, “评级历史记录”。“用户id”, “评级历史记录”。“对象id”, “评分历史记录”“时间戳”“评分历史记录”“分数”, “评级历史记录”。“额外”来自“评级历史记录”,其中 (“评级历史记录”。“内容类型id”=97和 评级历史。“对象id”=2876)排序依据 “评级历史记录”。“id”描述限制100;

                                                                QUERY PLAN
    -----------------------------------------------------------------------------------------------------------------------------------
     Limit  (cost=6708.03..6708.28 rows=100 width=58)
       ->  Sort  (cost=6708.03..6709.99 rows=783 width=58)
             Sort Key: id DESC
             ->  Bitmap Heap Scan on rating_ratinghistory  (cost=46.34..6678.11 rows=783 width=58)
                   Recheck Cond: (object_id = 2876)
                   Filter: (content_type_id = 97)
                   ->  Bitmap Index Scan on rating_ratinghistory_object_id_7bce52873f671c64_uniq  (cost=0.00..46.14 rows=1827 width=0)
                         Index Cond: (object_id = 2876)
    (8 rows)
    
    
    
    littlehome_db=# \d+ rating_ratinghistory;
                                                                 Table "public.rating_ratinghistory"
         Column      |           Type           | Collation | Nullable |                     Default                      | Storage  | Stats target | Description
    -----------------+--------------------------+-----------+----------+--------------------------------------------------+----------+--------------+-------------
     id              | integer                  |           | not null | nextval('rating_ratinghistory_id_seq'::regclass) | plain    |              |
     user_id         | integer                  |           | not null |                                                  | plain    |              |
     content_type_id | integer                  |           | not null |                                                  | plain    |              |
     object_id       | integer                  |           | not null |                                                  | plain    |              |
     rating_type     | smallint                 |           | not null |                                                  | plain    |              |
     score           | smallint                 |           |          |                                                  | plain    |              |
     time_stamp      | timestamp with time zone |           | not null |                                                  | plain    |              |
     extra           | jsonb                    |           |          |                                                  | extended |              |
    Indexes:
        "rating_ratinghistory_pkey" PRIMARY KEY, btree (id)
        "rating_ratinghistory_content_type_id" btree (content_type_id)
        "rating_ratinghistory_object_id_7bce52873f671c64_uniq" btree (object_id)
        "rating_ratinghistory_rating_type_5cf76626ba8bfa19_uniq" btree (rating_type)
        "rating_ratinghistory_time_stamp_60ddba37d740eb52_uniq" btree (time_stamp)
        "rating_ratinghistory_user_id" btree (user_id)
    Check constraints:
        "rating_ratinghistory_object_id_check" CHECK (object_id >= 0)
    Foreign-key constraints:
        "content_type_id_refs_id_47e22c61" FOREIGN KEY (content_type_id) REFERENCES django_content_type(id) DEFERRABLE INITIALLY DEFERRED
        "user_id_refs_id_d2d9be0d" FOREIGN KEY (user_id) REFERENCES custom_auth_customuser(id) DEFERRABLE INITIALLY DEFERRED
    Referenced by:
        TABLE "rating_ratinghistoryarchive" CONSTRAINT "rating_ratinghistory_ratinghistory_ptr_id_7ee35035_fk_rating_ra" FOREIGN KEY (ratinghistory_ptr_id) REFERENCES rating_ratinghistory(id) DEFERRABLE INITIALLY DEFERRED
    Options: autovacuum_vacuum_scale_factor=0.0, autovacuum_analyze_scale_factor=0.0, autovacuum_vacuum_threshold=10000
    
    
    # SELECT reltuples::bigint AS estimate FROM pg_class where relname='rating_ratinghistory';
     estimate
    ----------
     16845244
    (1 row)
    
    
    # select * from rating_ratinghistory limit 10;
        id    | user_id | content_type_id | object_id | rating_type | score |          time_stamp           | extra
    ----------+---------+-----------------+-----------+-------------+-------+-------------------------------+-------
     22846739 |   20298 |             103 |     31111 |          20 |       | 2019-09-15 18:49:49.572748+00 |
     17771225 |  253926 |              97 |      4062 |          40 |    10 | 2019-01-11 05:44:37.224198+00 |
     17771315 |      26 |             103 |     29050 |          20 |       | 2019-02-10 18:41:17.184759+00 |
     17771314 |  253399 |             103 |     29688 |          20 |       | 2019-02-10 18:41:17.187224+00 |
     17771312 |  173965 |             103 |     26608 |          20 |       | 2019-02-10 18:41:17.191079+00 |
     17771311 |  173965 |              97 |      3453 |          20 |       | 2019-02-10 18:41:17.1934+00   |
     17771310 |  251131 |             103 |     25990 |          20 |       | 2019-02-10 18:41:17.195314+00 |
     17771309 |  173965 |             103 |     28727 |          20 |       | 2019-02-10 18:41:17.198409+00 |
     17771308 |  173965 |              97 |      4839 |          20 |       | 2019-02-10 18:41:17.204428+00 |
     17771307 |  251131 |              97 |      2986 |          20 |       | 2019-02-10 18:41:17.207107+00 |
    
    0 回复  |  直到 4 年前
        1
  •  1
  •   Tim Biegeleisen    4 年前

    我并没有试图搞乱整个解释计划,但下面是我建议您查询的综合索引:

    CREATE INDEX idx ON rating_ratinghistory (content_type_id, object_id, id DESC);
    

    这包括 WHERE id 中出现的列 ORDER BY .