SQL Join與GROUP BY查詢優化

Question

我正在嘗試優化以下查詢。

 SELECT C.name, COUNT(DISTINCT I.id), COUNT(B.id)
   FROM Categories C, Items I, Bids B
  WHERE C.id = I.category
    AND I.id = B.item_id
  GROUP BY C.name
  ORDER BY 2 DESC, 3 DESC;

• 類別是一個有20條記錄的小桌子。
• Items是一個大表，具有50,000多個記錄。
• 出價是一個更大的表，具有超過60萬條記錄。

我有一個索引

Categories(name, id), Items(category), and Bids(item_id, id).

每個表的PRIMARY KEY是： Items(id), Categories(id), Bids(id)

有沒有可能優化查詢？ 非常感激。

Answer 1

沒有EXPLAIN (ANALYZE, BUFFERS)輸出，這是猜測。

查詢是如此簡單，以至於沒有什么可以優化的。

• 避免使正確的表格統計數字崩潰。 檢查EXPLAIN (ANALYZE)以查看PostgreSQL的估計是否正確。

• 增加shared_buffers ，以使整個數據庫都適合RAM（如果可以）。

• 增加work_mem以便所有哈希和排序都在內存中執行。

Answer 2

並非真的，您正在掃描所有記錄。

投標數據打中了多少項目記錄。 我可以想象所有表都經過全面掃描，並加入了哈希，並且忽略了索引。

Answer 3

query您的查詢似乎真的很簡單，並且我相信，由於表的大小，任何非真正低硬件的服務器都可以在心跳中運行此查詢。 但是，您總是可以使事情變得更好。 從理論上講，您可以進行以下優化，以提高查詢的性能：

• 從理論上講，這里最大的效率低下是您正在計算表的叉積而不是將它們連接在一起。 您可以使用以下聯接來重寫查詢：

 ... FROM Items I INNER JOIN Bids B ON I.id = B.item_id INNER JOIN Categories C ON C.id = I.category ... 

• 如果我們考慮所有性能，那么您在Items表的類別上的索引效率很低，因為您的索引只有20個條目映射到50K條目。 這是一個效率低下的索引，如果沒有該索引，您甚至可以獲得更好的性能。 但是，從實際的角度來看，這里還有很多其他問題需要考慮，因此這實際上並不是什么大問題。
• 您在Items表的ID列上沒有索引，並且在該列上具有索引可以加快您的第一次連接。 （但是PostgreSQL在主鍵列上有默認索引，因此這也不是什么大問題）

另外，在查詢的開頭添加解釋分析，將顯示PostgreSQL查詢計划程序用來運行查詢的計划。 如果您對查詢計划了解一兩件事，建議您也查看一下查詢結果，以發現任何遺漏的低效率之處。