的确是，最近一直在研究和写autovacuum的事情，但造化弄人，阴沟翻船的事情也是不少预见了，这次就遇到了。（让你前5篇嘚瑟）
先简化的说一下事情，因为要调整参数，找到怎么快速激发autovacuum工作的方法，在参数的调试中，掉入了黑洞。
1 环境：PG 11.7 CPU 2 core 内存 16G 磁盘普通SATA
2 参数配置 SB 4G autovacuum_mem 1G maintanence_work_mem 1G
3 通过pgbench 灌入大表数据
对数据库产生数据压力，80客户端 每个客户端10个进程 不间断的进行DML操作
通过系统表可以看到，这里的测试表的小表的 autovacuum 很快就进行清理了。
下面系统表展示了表的活的tuple ， 死的tuple 以及 死的tuple 占整体的总行的百分比。最后面是autovacuum 最后一次的时间。
下图可以看到只有1 亿的大表的 autovacuum last 的时间没有动，和其他表相比，上一次autovacuum 的时间在 7 个小时前。
基本上每秒死行在这个表上增加 200行左右。
根据前几篇写的，有的同学可能会提到，调整的参数
autovacuum_vacuum_threshold 和 autovacuum_vacuum_scale_factor 这两个参数，可以看到已经调整过了，实际上针对大表应该单独进行调整，这里就偷懒了。具体如何进行单表调整，看第三篇即可。
但是调整成这样系统大表 pgbench_accounts 还是没有进行 autovacuum
随即苦恼了一天，继续测试找问题，
此时估计有同学会提出，三个应该 autovacuum 的工作的原因
1 长事务影响，导致 autovacuum 不能进行工作
2 有复制槽影响，并且复制停止了，导致autovacuum 不能工作
3 因为autovacuum 的cost 过大导致不能进行 autovacuum的工作
这里可以排除以上三个原因，这边没有长事务，单机，并且相关的 cost 已经调整（具体 cost调整 看第四篇）
所以autovacuum 不工作，或者无法更好的工作的原因还有其他的，并且网上我没有找到描述这方面的原因。
原因 1 autovacuum 对大表操作时间过长，通过观察系统中的活动的进程，可以发现实际上autovacuum 在工作中，只是工作的时间较长。
其他的表本身在进行autovacuum 很快就完成了工作。
所以第一个原因并不是autovacuum没有工作，而是工作的时间太长。
从另一个角度可以证明，对于大表的参数应该是单独调整，不应该在整体的参数进行配置， 对于大表的autovacuum 应该控制频度。频度太低和太高都对大表的vacuum操作无益处。
原因2 众所周知，在autovacuum 操作中，会带有两个操作 1 vacuum 2 analyze, 在autovacuum 操作完毕后，需要进行 analyze 的操作， 而大表的vacuum analyze 也不是很快的，所以有些时间 autovacuum 不操作的原因也有 analyze的因素，长时间无法完成 analyze ,自然会影响 autovacuum的 真空操作。
所以以上两个原因都是针对大表的很长时间没有进行autovacuum操作的奇葩原因。
遇到上面的问题主要要考虑
1 是否需要对表进行分区处理，单表无法进行并发的autovacuum 的操作，将表分区可以提高针对表的vacuum 的速度
2 存储大表的数据磁盘，替换为SSD 磁盘
3 通过降低autovacuum_analyze_scale_factor 参数的，减少对大表的 analyze时时间过长，阻碍 autovacuum vacuum 。
4 定期晚上进行手动的 vacuum 对于大表 ，在手动vacuum 时会autovacuum针对这个表的操作会停止。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
相关推荐: openGauss数据库3.0.0升级5.0.0操作实践
文章目录 1.1 前言 1.2 升级须知 升级流程 升级方式 升级约束 1.3 升级前准备 1.4 升级操作 1.5 升级验证 1.6 提交升级 1.1 前言 openGauss是一款开源关系型数据库管理系统，采用木兰宽松许可证v2发行。之前基于3.0…
