计算不同列值的快速方法（使用索引？）

【问题标题】：Fast way to count distinct column values (using an index?)计算不同列值的快速方法（使用索引？）
【发布时间】：2019-08-19 14:37:39
【问题描述】：

问题：查询耗时过长

我有一个如下所示的新表，有 3e6 行：

CREATE TABLE everything_crowberry (
    id             SERIAL  PRIMARY KEY,
    group_id       INTEGER,
    group_type     group_type_name,
    epub_id        TEXT,
    reg_user_id    INTEGER,
    device_id      TEXT,
    campaign_id    INTEGER,
    category_name  TEXT,
    instance_name  TEXT,
    protobuf       TEXT,
    UNIQUE (group_id, group_type, reg_user_id, category_name, instance_name)
);

这通常对我的上下文有意义，并且大多数查询的速度都可以接受。

但是这样的查询并不快：

analytics_staging=> explain analyze select count(distinct group_id) from everything_crowberry;
                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=392177.29..392177.30 rows=1 width=4) (actual time=8909.698..8909.699 rows=1 loops=1)
   ->  Seq Scan on everything_crowberry  (cost=0.00..384180.83 rows=3198583 width=4) (actual time=0.461..6347.272 rows=3198583 loops=1)
 Planning time: 0.063 ms
 Execution time: 8909.730 ms
(4 rows)

Time: 8910.110 ms
analytics_staging=> select count(distinct group_id) from everything_crowberry;
 count 
-------
   481

Time: 8736.364 ms

我确实在group_id 上创建了一个索引，但是虽然该索引用于 WHERE 子句，但它并没有在上面使用。所以我得出结论，我误解了关于 postgres 如何使用索引的一些内容。注意（查询结果）有 500 个以下不同的 group_id。

CREATE INDEX everything_crowberry_group_id ON everything_crowberry(group_id);

任何我误解的指针或如何使这个特定查询更快？

更新

为了帮助解决 cmets 中提出的问题，我在此处添加了建议的更改。对于未来的读者，我已经包含了详细信息，以便更好地了解如何进行调试。

我在玩的时候注意到大部分时间都花在了初始聚合中。

seqscan

关闭 seqscan 会使情况变得更糟：

analytics_staging=> set enable_seqscan = false;

analytics_staging=> explain analyze select count(distinct group_id) from everything_crowberry;
                                                                         QUERY PLAN                                                                          
-------------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=444062.28..444062.29 rows=1 width=4) (actual time=38927.323..38927.323 rows=1 loops=1)
   ->  Bitmap Heap Scan on everything_crowberry  (cost=51884.99..436065.82 rows=3198583 width=4) (actual time=458.252..36167.789 rows=3198583 loops=1)
         Heap Blocks: exact=35734 lossy=316446
         ->  Bitmap Index Scan on everything_crowberry_group  (cost=0.00..51085.35 rows=3198583 width=0) (actual time=448.537..448.537 rows=3198583 loops=1)
 Planning time: 0.064 ms
 Execution time: 38927.971 ms

Time: 38930.328 ms

WHERE 会让情况变得更糟

限制为一组非常小的组 ID 会使情况变得更糟，而我可能认为计算一组更小的东西会更容易。

analytics_staging=> explain analyze select count(distinct group_id) from everything_crowberry WHERE group_id > 380;
                                                                         QUERY PLAN                                                                         
------------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=385954.43..385954.44 rows=1 width=4) (actual time=13438.422..13438.422 rows=1 loops=1)
   ->  Bitmap Heap Scan on everything_crowberry  (cost=18742.95..383451.68 rows=1001099 width=4) (actual time=132.571..12673.233 rows=986572 loops=1)
         Recheck Cond: (group_id > 380)
         Rows Removed by Index Recheck: 70816
         Heap Blocks: exact=49632 lossy=79167
         ->  Bitmap Index Scan on everything_crowberry_group  (cost=0.00..18492.67 rows=1001099 width=0) (actual time=120.816..120.816 rows=986572 loops=1)
               Index Cond: (group_id > 380)
 Planning time: 1.294 ms
 Execution time: 13439.017 ms
(9 rows)

Time: 13442.603 ms

解释（分析，缓冲）

analytics_staging=> explain(analyze, buffers) select count(distinct group_id) from everything_crowberry;
                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=392177.29..392177.30 rows=1 width=4) (actual time=7329.775..7329.775 rows=1 loops=1)
   Buffers: shared hit=16283 read=335912, temp read=4693 written=4693
   ->  Seq Scan on everything_crowberry  (cost=0.00..384180.83 rows=3198583 width=4) (actual time=0.224..4615.015 rows=3198583 loops=1)
         Buffers: shared hit=16283 read=335912
 Planning time: 0.089 ms
 Execution time: 7329.818 ms

Time: 7331.084 ms

work_mem 太小（参见上面的解释（分析，缓冲区））

将其从默认的 4 MB 增加到 10 MB 会有所改进，从 7300 ms 增加到 5500 ms 左右。

更改 SQL 也会有所帮助。

analytics_staging=> EXPLAIN(analyze, buffers) SELECT group_id FROM everything_crowberry GROUP BY group_id;
                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=392177.29..392181.56 rows=427 width=4) (actual time=4686.525..4686.612 rows=481 loops=1)
   Group Key: group_id
   Buffers: shared hit=96 read=352099
   ->  Seq Scan on everything_crowberry  (cost=0.00..384180.83 rows=3198583 width=4) (actual time=0.034..4017.122 rows=3198583 loops=1)
         Buffers: shared hit=96 read=352099
 Planning time: 0.094 ms
 Execution time: 4686.686 ms

Time: 4687.461 ms

analytics_staging=> EXPLAIN(analyze, buffers) SELECT distinct group_id FROM everything_crowberry;
                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=392177.29..392181.56 rows=427 width=4) (actual time=5536.151..5536.262 rows=481 loops=1)
   Group Key: group_id
   Buffers: shared hit=128 read=352067
   ->  Seq Scan on everything_crowberry  (cost=0.00..384180.83 rows=3198583 width=4) (actual time=0.030..4946.024 rows=3198583 loops=1)
         Buffers: shared hit=128 read=352067
 Planning time: 0.074 ms
 Execution time: 5536.321 ms

Time: 5537.380 ms

analytics_staging=> SELECT count(*) FROM (SELECT 1 FROM everything_crowberry GROUP BY group_id) ec;
 count 
-------
   481

Time: 4927.671 ms

创建视图是一项重大胜利，但可能会在其他地方产生性能问题。

analytics_production=> CREATE VIEW everything_crowberry_group_view AS select distinct group_id, group_type FROM everything_crowberry;
CREATE VIEW
analytics_production=> EXPLAIN(analyze, buffers) SELECT distinct group_id FROM everything_crowberry_group_view;
                                                                                                           QUERY PLAN                                                                                                            
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Unique  (cost=0.56..357898.89 rows=200 width=4) (actual time=0.046..1976.882 rows=447 loops=1)
   Buffers: shared hit=667230 read=109291 dirtied=108 written=988
   ->  Subquery Scan on everything_crowberry_group_view  (cost=0.56..357897.19 rows=680 width=4) (actual time=0.046..1976.616 rows=475 loops=1)
         Buffers: shared hit=667230 read=109291 dirtied=108 written=988
         ->  Unique  (cost=0.56..357890.39 rows=680 width=8) (actual time=0.044..1976.378 rows=475 loops=1)
               Buffers: shared hit=667230 read=109291 dirtied=108 written=988
               ->  Index Only Scan using everything_crowberry_group_id_group_type_reg_user_id_catego_key on everything_crowberry  (cost=0.56..343330.63 rows=2911953 width=8) (actual time=0.043..1656.409 rows=2912005 loops=1)
                     Heap Fetches: 290488
                     Buffers: shared hit=667230 read=109291 dirtied=108 written=988
 Planning time: 1.842 ms
 Execution time: 1977.086 ms

【问题讨论】：

  • 你能运行explain (analyze, buffers) 而不是只运行explain (analyze) 吗？也许在此之前使用set track_io_timing=on，这样我们也可以看到 I/IO 时序
  • 完成，问题已更新。我现在看到大部分时间都发生在聚合中，而不是 seqscan，所以是否使用索引可能是一个红鲱鱼。
  • "temp read=4693written=4693" 表示内存中没有足够的work_mem 进行聚合。
  • 你的 Postgres 版本是什么？我本来希望表的大小有一个并行 Seq 扫描和一个并行哈希聚合
  • 版本为 9.5。

标签： sql postgresql distinct postgresql-9.5 postgresql-performance


【解决方案1】：

对于group_id 中相对 少数 个不同的值（每组很多行）- 似乎是您的情况：

3e6 行 / 少于 500 个不同的 group_id

要使这个快速，您需要一个索引跳过扫描（又名松散索引扫描）。这在 Postgres 12 之前还没有实现。但是你可以通过递归查询来解决这个限制：

替换：

select count(distinct group_id) from everything_crowberry;

与：

WITH RECURSIVE cte AS (
   (SELECT group_id FROM everything_crowberry ORDER BY group_id LIMIT 1)
   UNION ALL
   SELECT (SELECT group_id FROM everything_crowberry
           WHERE  group_id > t.group_id ORDER BY group_id LIMIT 1)
   FROM   cte t
   WHERE  t.group_id IS NOT NULL
   )
SELECT count(group_id) FROM cte;

我使用 count(group_id) 而不是稍快的 count(*) 来方便地从最终递归中消除 NULL 值 - 因为 count(<expression>) 只计算非空值。

另外，group_id 是否可以是 NULL 也无关紧要，因为无论如何您的查询都不会将其计算在内。

可以使用你已有的索引：

CREATE INDEX everything_crowberry_group_id ON everything_crowberry(group_id);

相关：

对于group_id 中相对许多 个不同的值（每组几行） - 或对于小表 - 普通的 DISTINCT 会更快。通常在子查询中完成时最快，而不是在count() 中添加子句：

SELECT count(group_id) -- or just count(*) to include possible NULL value
FROM (SELECT DISTINCT group_id FROM everything_crowberry) sub;

【讨论】：

  • 很好的解释和简洁的解决方案！我稍微编辑了查询以删除对col 的引用，我认为这是编辑留下的
  • 哇，真快！谢谢！
  • 对于您的情况应该是几个数量级。哦，对于手头的查询，group_id 是否可以为 NULL 并不重要。 （对于其他查询可能。）
  • 是的，是 6 毫秒。
  • @jma：我的 rCTE 中的 WHERE t.group_id IS NOT NULL 实际上与表中的 NULL 值无关（尽管乍一看看起来很像）。在相关子查询没有找到下一个更大的group_id 之后停止递归的是中断条件，这导致t.group_id 中的值为NULL。
【解决方案2】：

我有时在 Postgres 中看到 count(distinct) 存在问题。

这是如何工作的？

select count(*)
from (select distinct group_id
      from everything_crowberry
     ) ec;

或者：

select count(*)
from (select distinct on (group_id) ec.*
      from everything_crowberry
     ) ec;

请注意，NULL 的处理方式略有不同，但可以轻松调整查询。

【讨论】：

  • 好建议！随着 work_mem 的增加（感谢@a_horse_with_no_name），查询需要 6000 毫秒。您的第一个建议是 4600 毫秒。我的 GROUP BY（上图）是 4900。创建 VIEW 是 2000。
猜你喜欢
  • 2018-09-18
  • 2011-11-14
  • 1970-01-01
  • 2013-07-22
  • 2018-05-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-11-10
相关资源
最近更新 更多
热门标签
Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode