首頁 > 資料庫 > mysql教程 > 為什麼我的 SELECT DISTINCT 查詢在具有複合主鍵的 Postgres 表上運行緩慢,如何提高其效能?

為什麼我的 SELECT DISTINCT 查詢在具有複合主鍵的 Postgres 表上運行緩慢,如何提高其效能?

Mary-Kate Olsen
發布: 2025-01-07 18:33:41
原創
361 人瀏覽過

Why is my SELECT DISTINCT query slow on a Postgres table with a composite primary key, and how can I improve its performance?

最佳化 Postgres 中緩慢的 SELECT DISTINCT 查詢

本文解決了在具有複合主鍵的大型 Postgres 表上執行 SELECT DISTINCT 查詢時遇到的效能問題。 檢查了涉及具有近 200 萬行和複合主鍵(product_id、trade_id)的表的特定場景。 雖然由於主鍵索引,SELECT DISTINCT product_id 查詢在理想情況下應該很快,但我們觀察到效能出乎意料地緩慢。

根本原因分析:

查詢規劃器選擇順序掃描而不是利用索引,被認為是瓶頸。這是由於表格的資料分佈造成的:只有40個唯一的產品ID,導致索引值重複程度很高。 這會導致大量索引探測和低效率的順序存取。

有效的解決方案:遞迴CTE

為了規避此限制並有效利用索引,提出了遞歸公用表表達式 (CTE) 作為 SELECT DISTINCT:

的更好替代方案
WITH RECURSIVE cte AS (
   (   -- parentheses required
   SELECT product_id
   FROM   tickers
   ORDER  BY 1
   LIMIT  1
   )
   UNION ALL
   SELECT l.*
   FROM   cte c
   CROSS  JOIN LATERAL (
      SELECT product_id
      FROM   tickers t
      WHERE  t.product_id > c.product_id  -- lateral reference
      ORDER  BY 1
      LIMIT  1
      ) l
   )
TABLE  cte;
登入後複製

這種遞歸 CTE 有效地模仿了索引跳躍掃描。它按排序順序迭代檢索不同的 product_id 值,從而避免與低效順序掃描相關的效能損失。 在 product_id 列上使用索引對於此方法的最佳效能至關重要。

重要提示:雖然Postgres 的索引跳過掃描功能正在開發中,但這種基於CTE 的解決方案為所描述的場景提供了強大且高效的解決方案,顯著提高了查詢效能。

以上是為什麼我的 SELECT DISTINCT 查詢在具有複合主鍵的 Postgres 表上運行緩慢,如何提高其效能?的詳細內容。更多資訊請關注PHP中文網其他相關文章!

本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
作者最新文章
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板