2在同一个DB表上几乎相同的选择需要非常不同的执行时间

时间:2017-12-22 08:54:26

标签: sql linux database postgresql pentaho-data-integration

圣诞节,我有一个问题,我真的想找到关于如何处理的线索..

我有一个报告数据库,它由来自卫星数据库的数据填充,在很多小型机器上。对于每个卫星DB,每20分钟均等地执行数据提取。他们使用所有相同的脚本。然而,它们在不同的装置上,遍布全国各地。

现在我有一个SELECT,由pentaho报告在此报告数据库中的同一个数据库表上执行。当一个SELECT需要几毫秒才能执行时,另一个需要几个小时。它们都在相同的表上执行,在相同的硬件上运行的同一个数据库中执行。

快速:

SELECT
 res.ticket_id,
 res.entry_zone,
 res.entry_time,
 res.exit_time,
 res.parking_time,
 res.cost,
 co.org_name,
 cu.firstname,
 cu.surname,
 a.name AS article_name,
 res.car_id 
FROM (SELECT
 lh.ticket_id,
 z.name AS entry_zone,
 lh.park_entered AS entry_time,
 lh.park_leaved AS exit_time,
 interval_to_hourminsec(lh.park_leaved - lh.park_entered) AS parking_time,
 lh.cost,
 lh.article_id,
 sa.contrib_user_id,
 fpl.car_id
 FROM longterm_history lh, zones z, sold_articles sa, flexcore_passing_log fpl
 WHERE lh.park_leaved BETWEEN  '2017-12-18 00:00' AND  '2017-12-19 23:59'
 AND sa.ticket_id = lh.ticket_id
 AND lh.entry_zone = z.zone_number
 AND lh.passlog_id = fpl.id
 AND lh.park_uuid = 100068
 AND z.park_uuid = 100068
 AND sa.park_uuid = 100068
 AND fpl.park_uuid = 100068
 AND lh.entry_zone = 1
) AS res 
LEFT OUTER JOIN articles a ON res.article_id = a.article_id AND a.park_uuid = 100068 
LEFT OUTER JOIN cont_users cu ON res.contrib_user_id = cu.id AND cu.park_uuid = 100068 
LEFT OUTER JOIN cont_orgs co ON cu.org_id = co.id AND co.park_uuid = 100068 
ORDER BY res.exit_time ASC

慢:

SELECT
 res.ticket_id,
 res.entry_zone,
 res.entry_time,
 res.exit_time,
 res.parking_time,
 res.cost,
 co.org_name,
 cu.firstname,
 cu.surname,
 a.name AS article_name,
 res.car_id 
FROM (SELECT
 lh.ticket_id,
 z.name AS entry_zone,
 lh.park_entered AS entry_time,
 lh.park_leaved AS exit_time,
 interval_to_hourminsec(lh.park_leaved - lh.park_entered) AS parking_time,
 lh.cost,
 lh.article_id,
 sa.contrib_user_id,
 fpl.car_id
 FROM longterm_history lh, zones z, sold_articles sa, flexcore_passing_log fpl
 WHERE lh.park_leaved BETWEEN  '2017-12-18 00:00' AND  '2017-12-19 23:59'
 AND sa.ticket_id = lh.ticket_id
 AND lh.entry_zone = z.zone_number
 AND lh.passlog_id = fpl.id
 AND lh.park_uuid = 100146
 AND z.park_uuid = 100146
 AND sa.park_uuid = 100146
 AND fpl.park_uuid = 100146
 AND lh.entry_zone = 1
) AS res 
LEFT OUTER JOIN articles a ON res.article_id = a.article_id AND a.park_uuid = 100146 
LEFT OUTER JOIN cont_users cu ON res.contrib_user_id = cu.id AND cu.park_uuid = 100146 
LEFT OUTER JOIN cont_orgs co ON cu.org_id = co.id AND co.park_uuid = 100146 
ORDER BY res.exit_time ASC

如何找出问题的位置,是什么导致第二个SELECT被执行几个小时?

我使用的是postgres SQL,服务器版本是9.6.3 通过pentaho数据集成将数据提取到数据库中

编辑:

通过EXPLAIN (ANALYZE, BUFFERS)运行两个查询后,最重要的区别在于此部分:

                                           ->  Bitmap Index Scan on longterm_history_park_uuid_idx  (cost=0.00..7609.82 rows=352718 width=0) (actual time=492.753..492.753 rows=354537 loops=1)
                                                 Index Cond: (park_uuid = 100068)
                                                 Buffers: shared read=1238

                                           ->  Bitmap Index Scan on longterm_history_park_uuid_idx  (cost=0.00..453.11 rows=20890 width=0) (actual time=4.680..4.680 rows=40021 loops=466475)
                                                 Index Cond: (park_uuid = 100146)
                                                 Buffers: shared hit=65306361 read=139

并且看起来第二个选择SELECT的速度慢于loops=466475而不是loops=1 dne。但我不知道它意味着什么或如何解决它..

EDIT2:

我找到tootl在线分享计划,这里有链接:

快速查询:https://explain.depesz.com/s/oYQLB

慢查询:https://explain.depesz.com/s/uOtf

慢速查询执行速度快,而提取已关闭:https://explain.depesz.com/s/4h4F

1 个答案:

答案 0 :(得分:1)

问题已经解决。

在学习如何通过大量基于Web的工具帮助阅读EXPLAIN ANALYZE以图形方式显示它之后,我注意到第二个(SLOWER)选择正在执行大量循环,并且优化器期望返回的行数少于它真的回来了。

这是基于优化器计算的错误数据的标志。为了解决这个问题,我在整个数据库上运行了VACUUM ANALYZE

结果显着改善了性能,查询执行时间从<4242437.080毫秒 缩短为547.202毫秒。