postgresql – Postgres查询优化(强制索引扫描)

前端之家收集整理的这篇文章主要介绍了postgresql – Postgres查询优化(强制索引扫描)前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
以下是我的查询.我试图让它使用索引扫描,但它只会seq扫描.

顺便提一下,metric_data表有1.3亿行.度量表有大约2000行.

metric_data表列:

metric_id integer,t timestamp,d double precision,PRIMARY KEY (metric_id,t)

如何获取查询以使用我的PRIMARY KEY索引?

SELECT
    S.metric,D.t,D.d
FROM metric_data D
INNER JOIN metrics S
    ON S.id = D.metric_id
WHERE S.NAME = ANY (ARRAY ['cpu','mem'])
  AND D.t BETWEEN '2012-02-05 00:00:00'::TIMESTAMP
              AND '2012-05-05 00:00:00'::TIMESTAMP;

说明:

Hash Join  (cost=271.30..3866384.25 rows=294973 width=25)
  Hash Cond: (d.metric_id = s.id)
  ->  Seq Scan on metric_data d  (cost=0.00..3753150.28 rows=29336784 width=20)
        Filter: ((t >= '2012-02-05 00:00:00'::timestamp without time zone)
             AND (t <= '2012-05-05 00:00:00'::timestamp without time zone))
  ->  Hash  (cost=270.44..270.44 rows=68 width=13)
        ->  Seq Scan on metrics s  (cost=0.00..270.44 rows=68 width=13)
              Filter: ((sym)::text = ANY ('{cpu,mem}'::text[]))
为了测试目的,您可以通过在当前会话中“禁用”顺序扫描强制使用索引:
SET enable_seqscan = OFF;

Details in the manual here.我引用“禁用”,因为实际上不能禁用顺序表扫描.但是Postgres现在可以选择任何其他可用选项.这将证明可以使用(metric_id,t)上的多列索引 – 不如在引导列上的索引那么有效.

如果将PRIMARY KEY中的顺序切换为(t,metric_id),则可能会获得更好的结果(不创建更多索引).

> Is a composite index also good for queries on the first field?

请注意,您通常不需要通过手动干预强制更好的查询计划.如果设置enable_seqscan = OFF导致更好的计划,有可能在您的安装过程中出现.考虑这个相关答案:

> Keep PostgreSQL from sometimes choosing a bad query plan

原文链接:https://www.f2er.com/postgresql/192692.html

猜你在找的Postgre SQL相关文章