【发布时间】：2019-09-13 03:03:57
【问题描述】：
最近我们在生产 Aurora PG 集群中遇到了性能问题。这是查询的解释分析。
大部分时间都花在了
Bitmap Index Scan on job_stage (cost=0.00..172.93 rows=9666 width=0) (actual time=238.410..238.410 rows=2019444 loops=1)扫描 2019444。然而，困扰我的是这个表中只有 70k 行。 Autovacuum 已打开，但 RDS 最近因另一个问题而超载。我们怀疑 autovacuum 落后了。如果是这样，它会解释我们观察到的扫描行超过表中的实际行吗？ 嵌套循环（成本=229.16..265.28 行=1 宽度=464）（实际时间=239.815..239.815 行=0 循环=1） -> 嵌套循环（成本=228.62..252.71 行=1 宽度=540）（实际时间=239.814..239.814 行=0 循环=1） 加入过滤器：（job.scanner_uuid =scanner_resource_pool.resource_uuid） 连接过滤器删除的行数：1 -> 在scanner_resource_pool 上使用scanner_resource_pool_scanner_index 进行索引扫描（成本=0.41..8.43 行=1 宽度=115）（实际时间=0.017..0.019 行=1 循环=1） 索引条件：((box_uuid = '5d8a7e0c-23ff-4853-bb6d-ffff6a38afa7'::text) AND (scanner_uuid = '9be9ac50-de05-4ddd-9545-ddddc484dce'::text)) -> 作业位图堆扫描（成本=228.22..244.23 行=4 宽度=464）（实际时间=239.790..239.791 行=1 循环=1） 重新检查条件：((box_uuid = '5d8a7e0c-23ff-4853-bb6d-ffff6a38afa7'::text) AND (stage = 'active'::text)) 索引重新检查删除的行数：6 堆块：精确=791 -> BitmapAnd (cost=228.22..228.22 rows=4 width=0) (实际时间=238.913..238.913 rows=0 loops=1) -> job_box_status 上的位图索引扫描（成本=0.00..55.04 行=1398 宽度=0）（实际时间=0.183..0.183 行=899 循环=1） 索引条件：（box_uuid = '5d8a7e0c-23ff-4853-bb6d-ffff6a38afa7'::text） -> job_stage上的位图索引扫描（成本=0.00..172.93行=9666宽度=0）（实际时间=238.410..238.410行=2019444循环=1） 索引条件：（stage = 'active'::text） -> 仅使用扫描仪上的 uc_box_uuid 进行索引扫描（成本=0.54..12.56 行=1 宽度=87）（从未执行） 索引条件：((box_uuid = '5d8a7e0c-23ff-4853-bb6d-ffff6a38afa7'::text) AND (uuid = '9be9ac50-de05-4ddd-9545-ddddc484dce'::text)) 堆取数：0 规划时间：1.274 ms 执行时间：239.876 毫秒
【问题讨论】：
标签： postgresql amazon-aurora postgresql-performance