【问题标题】:Postgresql Select query stuck in executionPostgresql Select 查询卡在执行中
【发布时间】:2020-06-11 10:34:31
【问题描述】:

我使用的是 PostgreSQL 版本 11。它包含数百万条数据。包括插入和更新在内的一切工作正常,但是当我使用一些过滤器运行选择查询时,它会卡住并且即使在 10 分钟 后也没有响应。

我正在使用这个简单的查询进行测试,但仍然卡住了。

select tweet_id, user_id 
from "TweetsData" 
where lid_id=1 and tweet_time<='2020-06-09 09:00:00' 
order by tweet_time desc limit 10

即使我没有得到此查询的 Explain Analyze 输出。

这是EXPLAIN

的输出
Limit  (cost=2053991.46..2053992.62 rows=10 width=43)
  ->  Gather Merge  (cost=2053991.46..3462030.09 rows=12068060 width=43)
        Workers Planned: 2
        ->  Sort  (cost=2052991.43..2068076.51 rows=6034030 width=43)
              Sort Key: tweet_time DESC
              ->  Parallel Seq Scan on "TweetsData"  (cost=0.00..1922598.21 rows=6034030 width=43)
                    Filter: ((tweet_time <= '2020-06-09 09:00:00'::timestamp without time zone) AND (lid_id = 1))

请帮助我解决这个问题?这是非常关键的。 提前致谢。

【问题讨论】:

  • 您是否为该列编制了索引?
  • 哪一栏?推特时间?我没有索引它。我使用这个数据库 5 到 6 个月。这个问题从今天开始。
  • 尝试只运行EXPLAIN - 即使它只是一个估计的计划:查询应该返回多少行?
  • @pifor EXPLAIN 的输出有问题,我用解释查询输出编辑了问题。
  • OK 由于LIMIT 10,查询只返回10行,但估计并行模式扫描大约12M行。

标签: sql postgresql query-performance


【解决方案1】:

如果没有可用的索引,计划者只能选择一个计划:扫描所有行,对它们进行排序、过滤,然后选择前 10 行。这意味着:从磁盘中获取 12M 条记录,只是为了获得 10 个结果元组。索引访问只需要从磁盘获取 x*10 页。 (x 在 0.1 到几十之间)

这里只使用了一个索引(在时间戳上)(列名略有不同):


select version();

\d tweets_created_at_idx

        -- Before jun 9
explain analyse
select id, user_id
from tweets
where sucker_id = 507                   -- low-cardinality condition
and created_at < '2020-06-09 09:00:00'  -- about 7M records
order by created_at desc
limit 10;

        -- After jun 9
explain analyse
select id, user_id
from tweets
where sucker_id = 507                   -- low-cardinality condition
and created_at >= '2020-06-09 09:00:00' -- about 5K records
order by created_at desc
limit 10;

输出:


                                                version                                                
-------------------------------------------------------------------------------------------------------
 PostgreSQL 11.3 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4, 64-bit
(1 row)

           Index "public.tweets_created_at_idx"
   Column   |           Type           | Key? | Definition 
------------+--------------------------+------+------------
 created_at | timestamp with time zone | yes  | created_at
btree, for table "public.tweets"

                                                                        QUERY PLAN                                                                        
----------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.43..1.65 rows=10 width=24) (actual time=0.059..0.079 rows=10 loops=1)
   ->  Index Scan Backward using tweets_created_at_idx on tweets  (cost=0.43..853049.60 rows=6995588 width=24) (actual time=0.052..0.071 rows=10 loops=1)
         Index Cond: (created_at < '2020-06-09 09:00:00+02'::timestamp with time zone)
         Filter: (sucker_id = 507)
 Planning Time: 0.339 ms
 Execution Time: 0.102 ms
(6 rows)

                                                                     QUERY PLAN                                                                      
-----------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.43..11.98 rows=10 width=24) (actual time=0.035..0.053 rows=10 loops=1)
   ->  Index Scan Backward using tweets_created_at_idx on tweets  (cost=0.43..6604.02 rows=5720 width=24) (actual time=0.034..0.050 rows=10 loops=1)
         Index Cond: (created_at >= '2020-06-09 09:00:00+02'::timestamp with time zone)
         Filter: (sucker_id = 507)
 Planning Time: 0.143 ms
 Execution Time: 0.067 ms
(6 rows)

在 RaspberryPi B 上输出(大约慢十倍)


                                                          version                                                          
---------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 11.5 on armv6l-unknown-linux-gnueabihf, compiled by gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516, 32-bit
(1 row)

Did not find any relation named "tweets_created_at_idx".
               Index "public.tweets_du_idx"
   Column   |           Type           | Key? | Definition 
------------+--------------------------+------+------------
 created_at | timestamp with time zone | yes  | created_at
 user_id    | bigint                   | yes  | user_id
btree, for table "public.tweets"

                                                                    QUERY PLAN                                                                     
---------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.43..7.16 rows=10 width=24) (actual time=0.337..0.481 rows=10 loops=1)
   ->  Index Scan Backward using tweets_du_idx on tweets  (cost=0.43..4796963.78 rows=7126207 width=24) (actual time=0.322..0.428 rows=10 loops=1)
         Index Cond: (created_at < '2020-06-09 09:00:00+02'::timestamp with time zone)
         Filter: (sucker_id = 507)
 Planning Time: 4.272 ms
 Execution Time: 0.828 ms
(6 rows)

                                                                  QUERY PLAN                                                                   
-----------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.43..7.75 rows=10 width=24) (actual time=0.202..0.435 rows=10 loops=1)
   ->  Index Scan Backward using tweets_du_idx on tweets  (cost=0.43..12876.25 rows=17588 width=24) (actual time=0.186..0.380 rows=10 loops=1)
         Index Cond: (created_at >= '2020-06-09 09:00:00+02'::timestamp with time zone)
         Filter: (sucker_id = 507)
 Planning Time: 8.428 ms
 Execution Time: 0.784 ms
(6 rows)

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-10-07
    • 2021-10-21
    • 1970-01-01
    • 2016-01-22
    • 1970-01-01
    • 2019-07-22
    • 2021-06-14
    • 2017-04-15
    相关资源
    最近更新 更多