【发布时间】：2020-08-04 16:15:56
【问题描述】：
我有一个名为 modifications 的表，有 42 列和 84M 行。总大小为 64GB。
我在 Amazon RDS 上运行 Postgres 9.6.11，在 db.m4.xlarge 实例上使用 16GB RAM。
当我运行一个简单的SELECT count(*) FROM modifications; 时，需要 380 秒才能完成执行。
当我运行SELECT * FROM modifications WHERE post_date = '2016-05-03'; 以限制单个日期时，返回结果中的 460 万行需要 156 秒。
当我将结果集进一步限制为大约 1M 行时，查询仍然需要 100 多秒才能完成。
我知道这些是大型结果集，但我对数据库查询性能测试相当陌生，所以我想要一些关于尝试什么的指针。
我在这些查询上运行了EXPLAIN ANALYZE，但我不确定该怎么做。其中许多查询非常简单，并且没有明确的方法来重组它们以提高性能。
我还尝试添加更多索引……我在每个最常查询的列上都有索引。
我正在使用 AWS RDS PostgreSQL 配置的默认设置，并尝试使用 SET LOCAL work_mem = 'XXXMB' 调整 work_mem 设置。这并没有什么不同。 shared_buffers (0.5GB) 和 effective_cache_size (0.5GB) 等其他默认设置是合理设置的。
任何有关如何解决此问题的建议或策略将不胜感激。如果我应该包含更多信息，请在 cmets 中告诉我。
编辑：这是最后一个 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)
【问题讨论】：
-
您应该对大多数查询使用瘦表。良好的索引也应该使其快速。我从哪里开始？在问题中包含每个查询的执行计划。通常，您应该首先使用
explain select ...查找问题的根源。在这个问题中发布结果。投入更多的硬件或资源很少有帮助。 -
@the-impaler 在帖子中添加了执行计划。 84M 行很多，但我觉得还有很多其他人的表比这更大，他们没有这样的基本性能问题。
-
@NicholasTulach 你确定这是查询的计划吗？该计划包括两个谓词...一个读取
change_type = 'residence_address_line_1'::text的谓词，我在您的查询中没有看到。如果您一次处理 1k、10k 或 100k 行，84 百万行应该不是问题。 -
这是我后面提到的
When i limit the result set even further to about 1M rows的计划。 -
"db.m4.xlarge instance" 使用 RDS，您可以选择独立于实例大小的存储类型和大小。您的 IO 类型和大小是什么？
标签： sql postgresql database-performance postgresql-9.6 sqlperformance