PostgreSQL：对具有复合键的大表的查询性能不佳

Answer 1

这个问题可能非常特定于 Aurora，我对此没有太多经验。

您的仅索引扫描结果有点令人惊讶。我认为不应该通过 7733 次缓冲区读取来获得 5658 行（加上 2 行过滤和 0 堆获取）。我不希望它需要超过 5700 次读取。但我知道 Aurora 的存储层与社区 PostgreSQL 有很大不同，所以也许这与它有关。无论如何，这只是减少了 25%，而不是您正在寻找的 10 倍。编辑：我意识到那些额外的读取是内部索引页面。起初我拒绝了这个想法，因为 2075 个内部页面与 5658 个叶子页面的比例是一个荒谬的比例。但后来我意识到，一个查询读取的叶子页面只是存在的所有叶子页面的一小部分，而读取的内部页面可能是存在的所有内部页面的大部分。这可能是您的测试方法中的一个缺陷。为了避免不公平地缓存数据，每次随机选择一个不同的 5000 a_id 就足够了。重新启动整个数据库（或您用来清除缓存的任何方法）都太过分了。如果它不是矫枉过正，因为您确实在每次查询之间重新启动生产数据库，那么，停止这样做。

每次读取大约 1 毫秒的读取时间对于使用好的 SSD 层的东西来说似乎相当慢（我自己的蹩脚的那个做得很好），但我找不到任何关于你应该从 Aurora 的存储层得到什么的好的数据。

我也很好奇行估计值下降了 30 到 50 倍。这是为什么？对此提出更准确的估计应该不难。但是，我认为不同的计划不会更快，所以估计真的不重要。但你永远不知道一个谜会把你引向何方。如果您只有 a_id IN-list 并删除其余列条件怎么办？编辑：我想我意识到了这个问题的答案，用于计算 pg_stats.n_distinct 的 PostgreSQL 采样方法存在微妙的偏差，在一个非常大的表聚集在被采样的列上的情况下，可能会大大低估 n_distinct（此处为 a_id） , n_distinct 对选择性估计非常重要。幸运的是，您可以使用 alter table app."table" alter a_id set (n_distinct = 9999999); 手动覆盖此估计值。但同样，这对你来说没什么用，因为没有更好的计划了。不过，这对于其他查询可能很重要。

但我认为你的赌注是退后一步。你为什么要运行这个查询？它的“商业案例”是什么？ 5000 个 id 的列表来自哪里？他们有什么模式吗？

Answer 2

您正在尝试优化查询性能冷缓存.

这是一个没有其他流量的实例。我们在桌子上跑了ANALYZE 和VACUUM ANALYZE

（除此之外，ANALYZE 单独对VACUUM ANALYZE 没有添加任何内容，所以这是多余的。）

为了优化，最小化数据页数必须阅读。 所以 ...

1. ...减少存储大小如果可能，每行。 （对于仅索引扫描，这对于所涉及的索引最重要。）

2. ... 增加数据局部性：同一数据页中的更多元组意味着要读取的页面更少。

   只需重新排序 PK 列

   你应该得到一些从简单地重新排序您的 PK 中的列得到改进。你现在有：

   primary key (a_id, b_id, c_id, d_ie, e_id)
   

   带领先a_id。不同a_id 的索引元组尽可能分散。正是您的查询的作用不是需要。你披露：

   b_id 有一个值 [...]
   d_id 有一个值（当前）
   e_id 有一个值（当前）
   c_id 的范围为 0-4
   a_id 的范围为 0-160,000,000

   将这样的列重新排序为最大化局部性对于您的查询：

   ALTER TABLE app.table ADD CONSTRAINT table_pk PRIMARY KEY (b_id, d_id, e_id, c_id, a_id) INCLUDE (a_date);
   

   由于b_id 和d_id / e_id（当前）是常数，因此它们只是噪声/镇流器。重要的部分是将c_id 移动到d_id 之前，这样，我们就不会用c_id IN (0,1,4) 接触索引的分支，并且更多的元组最终会出现在更少的索引页上。这是一种温和的效果，因为无论如何我们似乎都使用了一半的光谱。

   更激进

   由于b_id 是一个常数，因此不应从一开始就淡化PK。 d_id 和 d_id 也是如此如果它们实际上保持不变。

   我们的查询根本不需要e_id。

   这个改编的查询：

   SELECT a_id, 34 AS b_id, c_id, 0 AS d_id, a_date
   FROM   app.table ts
   WHERE  c_id IN (2,3)
   AND    a_id IN ( < 5000 VALUES > )
   

   ..结合这个索引将是好多了：

   CREATE INDEX foo ON app.table (c_id, d_id) INCLUDE (a_date)
   

   可能更好，但是：

   SELECT a_id, 34 AS b_id, 2 AS c_id, 0 AS d_id, a_date
   FROM   app.table ts
   WHERE  c_id = 2
   AND    a_id IN ( < 5000 VALUES > )
   UNION ALL
   SELECT a_id, 34 AS b_id, 3 AS c_id, 0 AS d_id, a_date
   FROM   app.table ts
   WHERE  c_id = 3
   AND    a_id IN ( < 5000 VALUES > )
   

   这应该只允许仅索引条件（查询计划中的Index Cond:）和查询计划中没有过滤器（Filter:）的仅索引扫描，以获得最大速度。

   甚至是最后一个查询的部分索引：

   CREATE INDEX foo_c2 ON app.table (d_id) INCLUDE (a_date) WHERE c_id = 2;
   CREATE INDEX foo_c3 ON app.table (d_id) INCLUDE (a_date) WHERE c_id = 3;
   

   允许更多的索引重复数据删除，因此涉及更少的索引页。
   为此考虑手册页的底部"Index-Only Scans and Covering Indexes"！