PostgreSQL 错了被别人指出，是人生幸事 vacuum 操作修正

问题是这样的，回答一个关于vacuum操作的问题的时候，由于学艺不精，知识不扎实，选择了错误的答案，有幸于马上有人指出错误。才不至于将错误的理解延续，所以的写一篇来将错误的理解纠正，并加深印象。

问题1 为什么要vacuum

postgresql 数据库并没有使用我们熟悉的类似于ORALCE ,MYSQL的redo,undo的数据库架构，PG独有的架构优点很多，但我们也必须面对部分的问题，在更新或删除PostgreSQL表中的行，会留下死行。Vacuum的作用可以去掉它们，这样空间就可以重复利用了。如果一个表没有被清空，它就会变得臃肿，这就会浪费磁盘空间并降低顺序表扫描的速度(在较小的范围内，还会降低索引扫描的速度)。

问题2 一般我们怎么处理

一般的情况下，我们通过上面的语句可以检测我们的autovacuum到底有没有执行，并且当前各个表的n_dead_tupd的情况如何。以及最近一次的 autovaccum 的情况。

问题 3 autovacuum 不管用怎么办？

事实上是的，如果autovacuum都百分之百的不出问题，那就没有这个话题了

所以有的时候，我们就需要vacuum 来处理一些问题

从下图可以看出，在执行了vacuum 后刚才还15个 dead tuple,已经变成了0

问题 4 vacuum autovacuum vacuum full 之间有什么不同

autovacuum

autovaccum 的主要功能自动执行vacuum 和 Analyze命令，autovacuum检测表有大量的inserted ,updated , deleted操作，另外还需要打开track_counts，否则autovacuum 将不能被正常使用。

autovacuum 实际上是由多个进程组成，主线程autovacuum 会在何时地时间调用，这里与 autovaccum_naptime 以及PG 如果有多个数据库地情况下，还和autovacuum_max_worker有关。每个worker process将检查每一个数据库表并且执行vacuum 和分析,这里官方文档中提及，当数据库中有大表情况下，很可能一个数据库一个autovacuum worker process 忙于处理大表，而让其表无法接受到autovacuum ，并且在一个数据库中可以有多少work process是没有限制的，work process 确实试图避免重复其他process已经完成的工作,运行的worker的数量并不计入max_connections。

Vacuum

真空的主要工作是回收被标记为dead 的元组占用的存储空间。回收的存储空间不会返回给操作系统，而是在同一个页面中进行整理，因此将来在同一个表中插入数据时可以重用它们。当对特定表执行真空操作时，可以同时对同一表执行其他读/写操作，因为对特定表不执行独占锁。如果没有指定表名，将对数据库的所有表执行VACUUM。

Vacuum 到当地做了什么是一个需要被了解的地方，之前也是迷迷糊糊

下面列一下

1 扫描所有表，或者特殊表，得到dead tuples

2 如果需要会固化需要清理的dead tuples

3 清理与dead tuples有关的index tuple

4 清理页面中的dead tuples 并将清理后的空间释放

5 更新对应表的FSM 和 VM 文件

6 更新相关的系统表

从上面看VACUUM 操作是非常耗费资源的，这也是其他数据库专家诟病POSTGRESQL 的一个地方，这里我们尽量不要去扫描所有的页，所以VM的存在是很必要的。

FULL Vacuum

从上面的解释看，Vacuum 已经满足了大部分的需求，那Full vacuum的操作的意义是什么，尽管VACUUM删除了所有无效的元组并对页面进行碎片整理以供将来使用，但它并不能帮助减少表的总体存储，因为实际上并没有将空间释放给操作系统。其实其他数据库也有类似的空间释放的方式，但实话是不怎么常用，当然这和他们的数据库原理有关，而放到pg里面可能由于本身的原理结构，这样的操作就被重视起来。

不愿意使用full vacuum 的原因是，他需要对系统有独占的权利

FULL Vacuum 到当地做了什么

1 对于表使用了独占锁 exclusive lock

2 创建一个并行的空的存储文件

3 将目前的标记为存活的tuples（行）拷贝到了新的存储中（其实就是新的物理文件）

4 在将原有的数据都拷贝后，开始释放原有的存储数据的文件

5 释放独占锁

其实上面的full vacuum 的操作让我想起 mysql 的

OPTIMIZE TABLE

ALTER TABLE table_name ENGINE = Innodb;

原理与full vacuum 基本上没有什么两样，或许人们已经习惯了 MYSQL 的曾经，但面对PG的类似的这样的操作和问题，就不那么淡定了，或许在心里暗暗的认为PG 这么高大上的数据库不应该存在这样问题。

其实反观商业数据库也有类似的问题，例如去shrink 一个 mdf 文件，ndf 文件，那也和死了一样的恐怖。