GaussDB(DWS) vacuum简述

1. 恢复或重用被已更新或已删除行所占用的磁盘空间。
2. 更新查询规划器使用的数据统计信息。
3. 更新可见性映射，它可以加速只用索引的扫描。
4. 保护老旧数据不会由于事务ID回卷或多事务ID回卷而丢失。

VACUUM和VACUUM FULL对比

VACUUM可以和生产数据库操作并行运行（SELECT、INSERT、UPDATE和DELETE等命令将继续正常工作，但在清理期间你无法使用ALTER TABLE等命令来更新表的定义）。

VACUUM FULL可以收回更多磁盘空间但是运行起来更慢，还会在其工作的表上加一个排他锁，因此无法和对此表的其他使用并行。

VACUUM移除表和索引中的废弃数据并将该空间标记为可在未来重用，不会把该空间交还给操作系统，除非在特殊的情况中表尾部的一个或多个页面变成完全空闲并且能够很容易地得到一个排他表锁。

VACUUM FULL通过新建一个完整的新版本表文件来降低空间。这将最小化表的尺寸，但是要花较长的时间。它需要额外的磁盘空间用于新建表。

vacuum执行过程中对表加4级锁，不影响表的增删改查。

vacuum full对表加8级锁，执行过程中表无法访问。

vacuum对列存表无效。

恢复磁盘空间

一般是多做VACUUM来避免VACUUM FULL。自动清理守护进会执行的就是VACUUM，不会执行VACUUM FULL。其思想不是让表保持它们的最小尺寸，而是保持磁盘空间使用的稳定状态：每个表占用的空间等于其最小尺寸外加清理之间被用完的空间。尽管VACUUM FULL可被用来把一个表收缩到最小尺寸并将该磁盘空间还给操作系统，但是如果该表将在未来再次增长这样就没什么意义。因此，对于维护频繁被更新的表，适度运行标准VACUUM运行比少量运行VACUUM FULL要更好。

一些管理员喜欢自己计划清理，例如在晚上负载低时做所有的工作。但也可能有问题，假如表出现预期之外的更新活动尖峰，膨胀得真正需要VACUUM FULL来回收空间。使用自动清理守护进程可以减轻这个问题，因为守护进程会根据更新活动动态规划清理操作。除非你的负载是完全可以预估的，完全禁用守护进程是不理智的。一种可能的折中方案是设置守护进程的参数（详见DWS产品文档自动清理章节），这样它将只对异常的大量更新活动做出反应，因而保证事情不会失控，而在负载正常时采用有计划的VACUUM来做批量工作。

当一个表因为大量更新或删除活动而包含大量死亡行版本时，如果需要回收它占用的过量磁盘空间，要使用VACUUM FULL，或者CLUSTER，或者ALTER TABLE的表重写变体之一。这些命令重写该表的一整个新拷贝并且为它构建新索引。所有这些选项都要求排他锁。注意它们也临时使用大约等于该表尺寸的额外磁盘空间，因为直到新表和索引完成之前旧表和索引都不能被释放。

如果一个表的整个内容会被周期性删除，考虑用TRUNCATE而不是先用DELETE再用VACUUM。TRUNCATE会立刻移除该表的整个内容，而不需要一次后续的VACUUM或VACUUM FULL来回收现在未被使用的磁盘空间。其缺点是会违背严格的 MVCC 语义。

“自动清理后台进程”实际上由多个进程组成。有一个称为 自动清理启动器的常驻后台进程， 它负责为所有数据库启动自动清理工作者进程。

清理阈值定义为：

清理阈值 = 清理基本阈值 + 清理缩放系数 * 元组数

临时表不能被自动清理访问。因此，临时表的清理和分析操作必须通过会话期间的SQL命令来执行。

注意：VACUUM会产生大量I/O流量，可能导致其他活动会话性能变差。

传送门：https://bbs.huaweicloud.com/blogs/245835