具有多：多连接的PostgreSQL查询非常慢

Question

问题：我需要找到带有指定 Hashtag 的帖子。 many:many 连接表称为 PostHashtag。但是，看起来内部连接太慢了：

EXPLAIN ANALYZE SELECT
    "Post"."id",
    "Post"."createdAt",
    "Post"."photo",
    "Post"."thumbnail",
    "hashtags->PostHashtag"."id" AS "hashtags.PostHashtag.id",
    "hashtags->PostHashtag"."hashtagId" AS "hashtags.PostHashtag.hashtagId",
    "hashtags->PostHashtag"."postId" AS "hashtags.PostHashtag.postId",
    "hashtags->PostHashtag"."createdAt" AS "hashtags.PostHashtag.createdAt",
    "hashtags->PostHashtag"."updatedAt" AS "hashtags.PostHashtag.updatedAt"
FROM
    "Posts" AS "Post"
INNER JOIN (
    "PostHashtags" AS "hashtags->PostHashtag"
    INNER JOIN "Hashtags" AS "hashtags" ON "hashtags"."id" = "hashtags->PostHashtag"."hashtagId"
) ON "Post"."id" = "hashtags->PostHashtag"."postId"
AND "hashtags"."name" = 'pumpupfam'
WHERE
    "Post"."photo" IS NOT NULL
AND "Post"."private" IS NULL
ORDER BY
    "Post"."createdAt" DESC
LIMIT 90;

产量

Limit  (cost=2651.58..2651.60 rows=7 width=212) (actual time=349.987..350.048 rows=90 loops=1)
  ->  Sort  (cost=2651.58..2651.60 rows=7 width=212) (actual time=349.985..350.013 rows=90 loops=1)
        Sort Key: "Post"."createdAt"
        Sort Method: top-N heapsort  Memory: 48kB
        ->  Nested Loop  (cost=18.80..2651.49 rows=7 width=212) (actual time=9.125..336.449 rows=30092 loops=1)
              ->  Nested Loop  (cost=18.37..2623.52 rows=19 width=28) (actual time=9.096..93.508 rows=31495 loops=1)
                    ->  Index Scan using hashtags_name_unique_index on "Hashtags" hashtags  (cost=0.42..8.44 rows=1 width=4) (actual time=0.034..0.036 rows=1 loops=1)
                          Index Cond: ((name)::text = 'pumpupfam'::text)
                    ->  Bitmap Heap Scan on "PostHashtags" "hashtags->PostHashtag"  (cost=17.94..2607.97 rows=711 width=28) (actual time=9.059..79.563 rows=31495 loops=1)
                          Recheck Cond: ("hashtagId" = hashtags.id)
                          Heap Blocks: exact=21507
                          ->  Bitmap Index Scan on posthashtags_hashtagid_fk_index  (cost=0.00..17.77 rows=711 width=0) (actual time=5.393..5.393 rows=31496 loops=1)
                                Index Cond: ("hashtagId" = hashtags.id)
              ->  Index Scan using "Posts_pkey" on "Posts" "Post"  (cost=0.43..1.46 rows=1 width=184) (actual time=0.006..0.007 rows=1 loops=31495)
                    Index Cond: (id = "hashtags->PostHashtag"."postId")
                    Filter: ((photo IS NOT NULL) AND (private IS NULL))
                    Rows Removed by Filter: 0
Planning time: 2.865 ms
Execution time: 350.289 ms

如何加快速度？

谢谢

Answer 1

您最好的选择可能是“Post”.“createdAt”上的索引，它可以向后走，根据需要在其他表中查找行，直到它累积 90。然后您还需要“hashtags-> 上的索引” PostHashtag"."postId" 和 hashtags.id.

->  Nested Loop  (cost=18.80..2651.49 rows=7 width=212) (actual time=9.125..336.449 rows=30092 loops=1)

但是，鉴于上述错误估计，可能很难让它使用这种方法。你可以set enable_sort=off 来测试我的首选方法是否可行（如果你有正确的索引应该是可行的），实际上是一种改进。

Answer 2

性能杀手是外部嵌套循环连接，原因是内部嵌套循环连接的错误估计和PostHashtags上的索引扫描。

修复内部嵌套循环添加的偏斜并不容易，但也许它足以改善对索引扫描的估计以倾斜：

ANALYZE "PostHashtags";

如果这修正了错误估计，请调整该表，以便自动分析更频繁地处理它。

要不然试试

SET default_statistics_target = 1000;
ANALYZE "PostHashtags";

看看这是否会改善对索引扫描的估计。

如果这样可以纠正错误估计，

ALTER TABLE "PostHashtags"
 ALTER "hashtagId" SET STATISTICS 1000;