我正在使用 PostgreSQL 9.6（Ubuntu 16.04），我有一个大约 10k 行的小表 T，其中每行在高峰时间每分钟更新 2 次（类似于UPDATE T SET c1 = ?, c2 = ? WHERE id = ?）。此外，这是在此表中完成的唯一更新操作，并且插入和删除根本不经常。
但是，我注意到SELECTT 中的查询有点慢，经过一番研究，我发现“PostgreSQL 中的更新实际上是 DELETE+INSERT (due MVCC) 的事务”。此外，我发现了类似的问题this one和this one，但与UPDATE查询有关。
我的问题是：连续频繁更新会减慢选择查询的速度吗？如果是这样，处理它的正确方法是什么？
如果一行被删除或更新，旧版本会被自动清理进程自动清理并重新使用空间。如果您只更新非索引列，则“删除/插入”部分实际上根本不会发生（称为“HOT - 仅堆元组”更新）。
使用较小的填充因子创建表可能是个好主意，以便在数据库块上留出空间来存储“新”行（您可能想尝试 60% 或 70% 之类的东西）
“频繁”更新通常只有在它们过于频繁以至于自动清理无法跟上，或者如果您有太多并发和打开的事务以至于自动清理无法释放任何空间时才会出现问题。很多时候，这可以通过使自动真空更具侵略性来缓解。
无论如何，通过索引列进行单行查找的查询不太可能受到频繁更新的影响。如果您确实看到减速，那么您可能希望reindex定期参加会议。
是的，正如你所说，频繁的更新/删除可能是查询缓慢的原因。因为，任何已删除的行（无论是实际的 DELETE 还是从 UPDATE 中删除）都只是标记为删除，并且实际上保留在数据页中，直到它用于另一个插入。为避免这种情况，您应该在桌子上运行适当的维护程序，例如 VACUUM。另一个简单的解决方案是，
create table similar_table;
insert into similar_table;
select * from original_table;
drop original_table;
alter table rename similar_table original_table;
这可以用于小表而不是使用 VACUUM。
您还应该查看查询计划。糟糕的查询也会使选择变慢。