SELECT DISTINCT 在我的 PostgreSQL 表上比预期的要慢

Posted

技术标签:

【中文标题】SELECT DISTINCT 在我的 PostgreSQL 表上比预期的要慢【英文标题】:SELECT DISTINCT is slower than expected on my table in PostgreSQL 【发布时间】:2021-06-27 19:54:05 【问题描述】:

这是我的表架构:

CREATE TABLE tickers (
    product_id TEXT NOT NULL,
    trade_id INT NOT NULL,
    sequence BIGINT NOT NULL,
    time TIMESTAMPTZ,
    price NUMERIC NOT NULL,
    side TEXT NOT NULL,
    last_size NUMERIC NOT NULL,
    best_bid NUMERIC NOT NULL,
    best_ask NUMERIC NOT NULL,
    PRIMARY KEY (product_id, trade_id)
);

我的应用程序在“ticker”频道上订阅 Coinbase Pro 的 websocket,并在收到消息时在代码表中插入一行。

该表现在有近 200 万行。

我假设运行 SELECT DISTINCT product_id FROM tickers 会很快,但它需要大约 500 到 600 毫秒。这是EXPLAIN ANALYZE 的输出:

HashAggregate  (cost=47938.97..47939.38 rows=40 width=8) (actual time=583.105..583.110 rows=40 loops=1)
  Group Key: product_id
  ->  Seq Scan on tickers  (cost=0.00..42990.98 rows=1979198 width=8) (actual time=0.030..195.536 rows=1979243 loops=1)
Planning Time: 0.068 ms
Execution Time: 583.137 ms

如果我通过运行SET enable_seqscan = FALSE(不是我想要真正依赖的东西,只是为了测试目的而这样做)来关闭 seq 扫描,那么查询会快一点。在 400 到 500 毫秒之间。这是EXPLAIN ANALYZE 的输出:

Unique  (cost=0.43..80722.61 rows=40 width=8) (actual time=0.020..480.339 rows=40 loops=1)
  ->  Index Only Scan using tickers_pkey on tickers  (cost=0.43..75772.49 rows=1980051 width=8) (actual time=0.019..344.113 rows=1980160 loops=1)
        Heap Fetches: 328693
Planning Time: 0.064 ms
Execution Time: 480.386 ms

表中只有 40 个唯一的产品 ID。我假设由于product_id 是复合主键的一部分,因此被索引,SELECT DISTINCT product_id FROM tickers 会快得多。但事实证明,查询计划器默认使用 seq 扫描而不是索引,即使我强制它使用索引,它仍然很慢(但比 seq 扫描快一点)。我意识到我可以创建另一个表来存储唯一的产品 ID 并对其进行查询,但我更关心的是为什么我对 tickers 表的查询需要这么长时间。

编辑#1: 我尝试仅在 product_id 列 (CREATE INDEX idx_tickers_product_id ON tickers (product_id)) 上创建索引,并且查询计划程序仍然执行顺序扫描,除非我首先运行 SET enable_seqscan = FALSE。但它的性能比使用复合 PK 索引时稍好(快 10 到 50 毫秒)。

编辑#2: 我尝试了 Erwin Brandstetter 的解决方案,它大大提高了速度。表中现在有 225 万行,执行只需要 0.75 毫秒!

编辑#3: 我想增加接受的解决方案,以检索代码计数 (max(trade_id) - min(trade_id) + 1) 以及每个产品 ID 的最小和最大时间。我为此创建了一个新问题: How to use index skip emulation in PostgreSQL to retrieve distinct product IDs and also min/max for certain columns

【问题讨论】:

我也希望进行全索引扫描,但是有时候,顺序读取表而不是通过索引查找路径会更快。几乎肯定会单独使用 product_id 的附加索引。 在其他 DBMS 中使用称为“索引跳过扫描”的访问路径会更有效,但不幸的是 Postgres 还没有。提高性能的一种方法是使用group by,因为它可以利用并行扫描。 谢谢@ThorstenKettner。我尝试将索引仅添加到 product_id 列以查看它会做什么。有关详细信息,请参阅问题中的“EDIT #1”。 我知道您已经找到了一个很好的解决方案,但是仅索引扫描并不比 seq 扫描快很多的一个原因是它必须访问堆 300k 次。这可能是 postgres 选择 seq 扫描的原因。清理表以更新可见性映射,仅索引扫描会快得多。 谢谢@Jeremy。随着更多行添加到表中,我是否必须再次运行? 【参考方案1】:

虽然 Postgres 中还没有索引跳过扫描,但请模拟一下:

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;

(product_id) 上有一个索引,表中只有 40 个唯一的产品 ID,这应该是快速。大写F(product_id, trade_id)上的PK指数也不错!

每个product_id(与您的数据分布相反)只有很少的行,DISTINCT / DISTINCT ON 将同样快或更快。

实施索引跳过扫描的工作正在进行中。 见:

Select first row in each GROUP BY group? Optimize GROUP BY query to retrieve latest row per user Is a composite index also good for queries on the first field?

【讨论】:

这太棒了!我不熟悉递归 CTE 和 CROSS JOIN LATERAL,所以我有一些功课要做。无论如何,执行只需要 0.75 毫秒。也将其添加到我原来的问题中。 是否可以利用这种方法来检索每个唯一产品 ID 的最小和最大交易 ID 以及最小和最大时间?还是这种方法主要是为了获得不同的值? @RichardGieg:一切皆有可能。获得最小值 最大值会使事情复杂化,但仍然可能。为简单起见,您可以运行多个非常快速的查询。一旦你有了不同的 product_id 列表,你就可以重复使用它来使额外的查询更简单、更快。我添加的链接之一中的详细指南:***.com/questions/25536422/… 如果您不知所措,请再问一个问题。您可以在此处发表评论以链接转发... 我的新问题:***.com/questions/66895595/…

以上是关于SELECT DISTINCT 在我的 PostgreSQL 表上比预期的要慢的主要内容,如果未能解决你的问题,请参考以下文章

TypeORM select with case insensitive distinct

MySQL SELECT DISTINCT 多列

SQL 窗口函数 - SELECT DISTINCT ORDER BY LIMIT

SQL 性能:SELECT DISTINCT 与 GROUP BY

MYSQL:SELECT 方法 - 但不显示重复项/GROUP 或 DISTINCT?

MYSQL 查询慢 SELECT DISTINCT