我已经从大约 7500 万行的 PostgreSQL 表中删除了大约 6500 万行。删除查询一完成，CPU 就骤降到 100%，持续约五分钟。
删除行的表有多个索引，并且在删除期间和删除之后被大量使用。不幸的是，我没有办法重现这个问题，因为它发生在生产环境中。
autovacuum 是否可能启动？如果是，它是否可以将具有 32 个 CPU 核心的数据库驱动到 100% CPU 使用率？如果是这样，是否有办法限制 autovacuum 的摄入量，以便在大量删除查询后不会降低数据库性能？
我正在使用 PostgreSQL 版本 14.8。
我使用的是较旧版本的 Postgres (8.4.20)。我知道 autovacuum 进程经常执行以释放删除或更新表中数据的查询的磁盘空间。我有一个不经常删除或更新的数据库。
在这样的数据库上处理 autovacuum 需要更少的时间和内存，还是仅取决于数据库中对象的大小和数量？
在 postgresql 9.4 上，我有一个从未有任何更新或删除的表，只有插入和选择。因此它永远不会被自动吸尘，但它仍然会被自动分析，当它发生时，它可能需要 100 多秒。在那 100 秒和之后的很长一段时间内，数据库性能很糟糕，我的应用程序报告的数据库响应时间在 40-150 秒范围内，而不是正常的 2 毫秒范围内。
我一直听说你不应该禁用自动真空，但是当我为这个表设置 autovaccum_enabled=false 时，数据库的性能要可靠得多。是否有理由在这张桌子上启用它？查询计划器最终是否会因为没有在永远不会更新或删除的表上运行自动分析而受到影响？有没有更好的方法来解决这个问题？
编辑：潜在地修改该表的 autovacuum_analyze_threshold 和 autovacuum_analyze_scale_factor 以使分析更频繁地发生会更好吗？
在监视我的数据库上的 autovacuum 活动时，我注意到标记为 的 autovacuum(to prevent wraparound)似乎比“常规” autovacuum 花费的时间更长。这让我开始尝试了解各种“种类”或 autovacuum 的性能/行为差异。
从文档中，我确定了 autovacuum 可能VACUUM是一张桌子的几个不同原因：
该表具有需要冻结的旧事务 ( relfrozenxid > min(autovacuum_freeze_max_age, table.autovacuum_freeze_max_age)。这就是“ (to prevent wraparound)”自动真空。
自上次以来表中过时的元组数VACUUM超过“真空阈值”
还有其他我想念的吗？
手册VACUUM中似乎暴露的“攻击性”旋钮是FREEZE和DISABLE_PAGE_SKIPPING。这些不同类型的 autovacuum 是否曾经使用过这些选项，如果是，什么时候使用？
Postgres 建议使用 autovacuum 删除死元组。但是运行 autovacuum 最终会使对同一个表的其他查询变慢吗？它是否添加了影响性能的锁（行级或表级）？CPU 上是否有重大负载或是否消耗了大量内存。
这将帮助我们决定是否应该为我们的一个具有大量写入和删除的表打开自动清理，或者我们是否应该在非高峰时间定期运行手动清理。
我遇到一个问题，似乎我的数据库中的一些大型表没有被 autovacuum 守护进程清理。这是我所看到的：
SELECT schemaname, relname, n_live_tup, n_dead_tup, last_autovacuum
FROM pg_stat_all_tables
ORDER BY n_dead_tup DESC LIMIT 5;
+------------+-----------------------------+------------+------------+-------------------------------+
| schemaname | relname | n_live_tup | n_dead_tup | last_autovacuum |
+------------+-----------------------------+------------+------------+-------------------------------+
| md | calculation_log_item | 35989527 | 3559253 | 2020-07-13 03:41:37.49764-04 |
| audit | transaction_statement | 700356 | 557278 | NULL |
| audit | record_history | 701635 | 438849 | NULL |
| md | program_requirement_state | 193500 | 29204 | 2020-07-14 03:06:02.339032-04 |
| md | calculation_log …