如上篇文章提到，如果出现了autovacuum的问题，那么这可能是个悲伤的故事。怎么解决？

笔者觉得可以从如下几个方面着手去考虑解决问题，可以避免一些坑。
        1)持续观察，是不是autovacuum问题一直存在，如果只是偶尔出现一次，可能不需要那么慌张。因为很有可能是其他异常情况造成的。比如当时正在做大规模数据迁移等操作，这种操作如果是偶发的，大可不必在意。

2) 笔者一般的分析思路是从大到小，比如先检查外围的关键配置项，如果有必要的话，再去深究postgres autovacuum相关的配置项。因为总体来说，调优和分析问题时要切记舍本逐末。就这个问题而言，我们知道数据库的读写操作，可以先分开看，这样比较容易理解。读，是从disk读取到OS(操作系统，如Windows/Linux等) cache,再抓取到postgres cache(buffer)，是这样一个过程。而写的操作相反，从postgres cache 先写到os cache，再最后写入disk。所以说了那么多，是想表达，外围的设置非常关键，postgres服务器也应该预留足够的资源给操作系统（如内存，最好能达到20%，甚至更多一点），如果忽略了大的方面的配置检查和作业，很可能会使调优工作走向不归路。

3)如上篇文章提到的，autovacuum相关的配置，有大致12个之多，但是真正在开始调整这些参数时要注意的是，有些参数从我的经验来看，最好先不要动，比如“autovacumm_max_workers”;其默认值为3，当某些表dead tuple增多时，特别是占用了50%以上tuples的时候，可以先调小参数“autovacuum_vacuum_scale_factor”的值。比如可以从默认的0.2调整为0.1，增加vacuum的频率，可能就能解决问题。autovacumm_max_workers最好先不动，是因为如果动了它，可能会有一些副作用，得不偿失，具体会在第4点说明。之前笔者在项目中就遇到了这样的坑。

4)如果此时vacuum的问题解决之后，发现有些SQL执行还是很慢，通过监控可能发现SQL执行时间起伏比较大。那么我们要知道一点的是，autovacuum过程不只做了vacuum的动作，其实还做了另外一个动作，那就是“Analyze"，通俗来说，这个动作就是为了完成在tuples更新（磁盘更新）之后，执行计划也应该相应更新，以求得到最佳/最优执行计划等等，也很关键。大家可以通过调整“autovacuum_analyze_scale_factor”或参数“autovacuum_analyze_threshold”,如果对于表记录过多，如超过10000行，可以直接考虑调整前一个参数即可。

Autovacuum的问题调优，到这里告一段落。如果有其他问题或者项目中遇到奇怪的和autovacuum相关的问题，欢迎留言。

大家也可以扫描并关注如下公众号“TimTest”，会有更多性能测试相关内容分享。