Postgres中的查詢優化速度慢

Question

我們遇到了特定SQL查詢的性能問題，我們試圖弄清楚如何在這里改進。 它的執行時間大約是20 - 100秒！

這是查詢，它的解釋如下：

SELECT  "jobs".* FROM "jobs"
  WHERE "jobs"."status" IN (1, 2, 3, 4)
  ORDER BY "jobs"."due_date" ASC
  LIMIT 5;


Limit  (cost=0.42..1844.98 rows=5 width=2642) (actual time=16927.150..18151.643 rows=1 loops=1)
   ->  Index Scan using index_jobs_on_due_date on jobs  (cost=0.42..1278647.41 rows=3466 width=2642) (actual time=16927.148..18151.641 rows=1 loops=1)
         Filter: (status = ANY ('{1,2,3,4}'::integer[]))
         Rows Removed by Filter: 595627
 Planning time: 0.205 ms
 Execution time: 18151.684 ms

我們在AWS RDS上使用PostgreSQL 9.6.11。

在一個表中，我們有~500K行。 適用於查詢的字段是：

• due_date（沒有時區的時間戳，可以為null）
• status（整數，非null）

我們有以下索引：

CREATE INDEX index_jobs_on_due_date ON public.jobs USING btree (due_date)
CREATE INDEX index_jobs_on_due_date_and_status ON public.jobs USING btree (due_date, status)
CREATE INDEX index_jobs_on_status ON public.jobs USING btree (status)
CREATE UNIQUE INDEX jobs_pkey ON public.jobs USING btree (id)

提前謝謝你，傑克

Answer 1

對於此查詢：

SELECT  j.*
FROM "jobs" j
WHERE j."status" IN (1, 2, 3, 4)
ORDER BY "jobs"."due_date" ASC
LIMIT 5;

“明顯”指數處於(status) 。 但這可能沒有用。 目標是擺脫排序。 因此，您可以重寫查詢並使用索引jobs(status, due_date) ：

select j.*
from ((select j.*
       from jobs j
       where j.status = 1
       order by j.due_date asc
       limit 5
      ) union all
      (select j.*
       from jobs j
       where j.status = 2
       order by j.due_date asc
       limit 5
      ) union all
      (select j.*
       from jobs j
       where j.status = 3
       order by j.due_date asc
       limit 5
      ) union all
      (select j.*
       from jobs j
       where j.status = 4
       order by j.due_date asc
       limit 5
      )
     ) j
order by due_date
limit 5;

子查詢應該都使用復合索引。 最后的排序將是（最多）20行，這應該很快。

編輯：

這是一個相關的想法，具有相同的索引：

SELECT j.*
FROM (SELECT  j.*,
              ROW_NUMBER() OVER (PARTITION BY j.status ORDER BY j.due_date ASC) as seqnum
      FROM "jobs" j
     ) j
WHERE j.status in (1, 2, 3, 4) AND seqnum <= 5
ORDER BY j.due_date ASC
LIMIT 5;

這可以使用ROW_NUMBER()計算的索引。 這可能需要對表進行全表掃描。 但是，最終的排序將限制為20行，因此最終排序將被消除。