提高JOIN和子SELECT的查詢性能

我有一個相當複雜的查詢，它有多個內部連接以及一個子選擇。這是可怕執行：提高JOIN和子SELECT的查詢性能

EXPLAIN ANALYZE SELECT 
    SUM(weekly_baskets.servings/2) AS sum_weekly_baskets_servings_2, 
    meal_selections.meal_id AS meal_selections_meal_id 
FROM 
    "meal_selections" 
INNER JOIN 
    "weekly_baskets" "weekly_baskets_meal_selections" 
     ON "weekly_baskets_meal_selections"."id" = "meal_selections"."weekly_basket_id" 
INNER JOIN 
    "weekly_baskets" 
     ON "meal_selections"."weekly_basket_id" = "weekly_baskets"."id" 
WHERE 
    "weekly_baskets"."menu_id" = 344 
    AND (
     NOT (EXISTS (SELECT 
     1 
     FROM 
     "cancellations" 
     WHERE 
     ("cancellations"."cancellable_id" = "weekly_baskets"."id") 
     AND ("cancellations"."cancellable_type" = 'WeeklyBasket') 
     AND "cancellations"."active" = 't')) 
    ) 
GROUP BY 
    meal_selections.meal_id

這裏的查詢計劃：

HashAggregate (cost=122273.42..122275.79 rows=787 width=8) (actual time=32313.598..32313.602 rows=13 loops=1) 
    Group Key: meal_selections.meal_id 
    -> Nested Loop (cost=26501.36..122208.17 rows=43504 width=8) (actual time=97.199..32292.526 rows=48594 loops=1) 
     -> Nested Loop (cost=26501.28..119314.73 rows=19567 width=12) (actual time=97.175..20446.310 rows=16067 loops=1) 
       -> Nested Loop Anti Join (cost=26501.19..87846.01 rows=19567 width=8) (actual time=97.146..20274.526 rows=16067 loops=1) 
        -> Bitmap Heap Scan on weekly_baskets (cost=26501.11..62382.74 rows=33112 width=8) (actual time=97.049..15395.178 rows=34502 loops=1) 
          Recheck Cond: (menu_id = 344) 
          Heap Blocks: exact=12414 
          -> Bitmap Index Scan on index_weekly_baskets_on_user_id_and_menu_id (cost=0.00..26499.45 rows=33112 width=0) (actual time=94.135..94.135 rows=34514 loops=1) 
           Index Cond: (menu_id = 344) 
        -> Index Only Scan using uidx_cancellations_for_active on cancellations (cost=0.08..0.77 rows=1 width=4) (actual time=0.141..0.141 rows=1 loops=34502) 
          Index Cond: ((cancellable_id = weekly_baskets.id) AND (cancellable_type = 'WeeklyBasket'::text) AND (active = true)) 
          Heap Fetches: 12907 
       -> Index Only Scan using weekly_baskets_pkey on weekly_baskets weekly_baskets_meal_selections (cost=0.09..1.61 rows=1 width=4) (actual time=0.004..0.010 rows=1 loops=16067) 
        Index Cond: (id = weekly_baskets.id) 
        Heap Fetches: 16595 
     -> Index Only Scan using index_meal_selections_on_weekly_basket_id_and_meal_id on meal_selections (cost=0.09..0.14 rows=4 width=8) (actual time=0.508..0.737 rows=3 loops=16067) 
       Index Cond: (weekly_basket_id = weekly_baskets_meal_selections.id) 
       Heap Fetches: 47391 
Planning time: 1.568 ms 
Execution time: 32313.715 ms

顯然，這是非常痛苦的。我很難用可能使用LATERAL連接來優化這個查詢，但一直未能圍繞它來包裝我的頭。

來源

2016-07-27 Charles Kirk

什麼時候是你最後一次抽真空或真空滿了你的桌子？有一些slow-ish嵌套循環，但是大的計時器是僅索引掃描（在'meal_selections'和'cancellations'上），並且在'weekly_baskets'上索引堆提取。這些表格可能需要注意，或者它們非常大。 – jmelesky

大約6天前最後一次吸塵，是一個全手動真空。死行數量非常低。你說得對，'meal_selections'有大約5m行，'cancellations'有大約1.1m行。 –

你的加入「weekly_baskets」「weekly_basket_meal_selections」似乎沒有被使用在任何地方。你應該刪除它。除非我誤讀你的查詢，這可能是 –

嘗試將您的子選擇更改爲左連接並將其檢查爲空，這應該有所幫助。

SELECT 
    SUM(weekly_baskets.servings/2) AS sum_weekly_baskets_servings_2, 
    meal_selections.meal_id AS meal_selections_meal_id 
FROM 
    "meal_selections" 
INNER JOIN 
    "weekly_baskets" "weekly_baskets_meal_selections" 
     ON "weekly_baskets_meal_selections"."id" = "meal_selections"."weekly_basket_id" 
INNER JOIN 
    "weekly_baskets" 
     ON "meal_selections"."weekly_basket_id" = "weekly_baskets"."id" 
LEFT JOIN "cancellations" on 
     "cancellations"."cancellable_id" = "weekly_baskets"."id" 
     AND "cancellations"."cancellable_type" = 'WeeklyBasket' 
     AND "cancellations"."active" = 't' 
WHERE 
    "weekly_baskets"."menu_id" = 344 
    AND "cancellations"."cancellable_id" is null 
GROUP BY 
    meal_selections.meal_id

來源

2016-07-27 17:27:43

這不會讓查詢不快。 –

你能否用這個新提出的查詢的解釋分析來更新你的問題。這似乎是一個好主意（+1），因爲NOT IN查詢通常有點慢，通過消除它，我們應該加快速度 – e4c5

提高JOIN和子SELECT的查詢性能

回答

相關問題