Question

我有一个名为modifications的表，具有42列和8400万行。总大小为64GB。

我正在db.m4.xlarge实例上在具有16GB RAM的Amazon RDS上运行Postgres 9.6.11。

当我运行简单的SELECT count(*) FROM modifications;时，需要380秒才能完成执行。

当我运行SELECT * FROM modifications WHERE post_date = '2016-05-03';将日期限制为一个日期时，需要156秒才能返回结果中的460万行。

当我将结果集进一步限制到大约100万行时，查询仍然需要100多秒才能完成。

我知道这些是很大的结果集，但是我对数据库查询性能测试还是个新手，所以我想尝试一下。

我已经对这些查询运行EXPLAIN ANALYZE，但是我不确定该怎么做。这些查询中的许多非常简单，并且没有清晰的方法来重组它们以提高性能。

我还尝试添加更多索引...我在每个最常查询的列上都有索引。

我正在使用AWS RDS PostgreSQL配置的默认设置，并尝试使用work_mem来调整SET LOCAL work_mem = 'XXXMB'设置。那并没有改变。合理设置了shared_buffers（0.5GB）和effective_cache_size（0.5GB）之类的其他默认设置。

任何有关如何解决故障的建议或策略，将不胜感激。如果我应该提供更多信息，请在评论中让我知道。

编辑：这是最后一个SELECT查询的执行计划

Bitmap Heap Scan on modifications  (cost=479407.01..1692971.07 rows=460492 width=279)
  Recheck Cond: ((post_date = '2016-05-03 00:00:00'::timestamp without time zone) AND (change_type = 'residence_address_line_1'::text))
  ->  BitmapAnd  (cost=479407.01..479407.01 rows=460492 width=0)
        ->  Bitmap Index Scan on modifications_post_date_idx  (cost=0.00..130733.87 rows=4478040 width=0)
              Index Cond: (post_date = '2016-05-03 00:00:00'::timestamp without time zone)
        ->  Bitmap Index Scan on modifications_change_type_idx  (cost=0.00..348442.64 rows=8677610 width=0)
              Index Cond: (change_type = 'residence_address_line_1'::text)

Answer 1

您应该打开track_io_timing，然后执行EXPLAIN (ANALYZE, BUFFERS)来查看查询的性能。

对于您显示的计划查询，最好在(change_type, post_date)上具有多列索引。但是，拥有数百个多列索引来支持数百个不同的查询是不可行的。因此，您应该同时使用多列索引和两个单列索引查看EXPLAIN (ANALYZE, BUFFERS)的查询。

您列出了3个截然不同的查询。哪一个是您最关心的人？通常，您需要优化查询以提供所需的结果，而不能根据优化的难易程度来选择完全不同的查询。

我从哪里开始诊断PostgreSQL性能问题？

1 个答案: