23.1 日常Vacuuming

Postgresql数据库要求定期的维护通过Vacuuming。对于许多安装的数据库，vacuuming的执行时用过autovacuumdaemon(自动收集信息执行的守护进程)。你可以通过调整autovacuuming 参数从而获得最佳的结果在你所在的环境中。有些数据库管理员需要替换vacuum守护进程,可以使用任务调度来完成。本质将在接下来的章节中讨论。管理员也依靠其本质帮助他们了解和修改autovacuuming的参数。

23.1.1 Vacuuming的基础

Postgresql的VACUUM执行在每一个表上的存在以下几个原因：

1.需要覆盖或者重新使用由于update和delete操作引起的磁盘空间；

2.更新数据的统计信息用在Postgresql的执行计划中；

3.通过更新索引的信息，加速唯一性索引扫描的效率；

4.为了防止由于事务ID或者multixact ID重复而丢失老数据；

任何一个原因在执行VACUUM是都有一定的使用频率和范围，在接下来的章节中会解释。

Vacuum有两种形式：标准VACUUM和VACUUM FULL。VACUUM FULL能释放更多的磁盘空间但是执行比较慢。而且标准VACUUM可以在生产库中并行操作。（SELECT，INSERT，UPDATE和DELETE命令能够照常执行，但是不能执行修改表结构的操作如ALTER TABLE命令。）VACUUM FULL会获取一个排它锁，所以不能并行执行在其他的表。所以通常管理员应该尽量使用标准VACUUM而不是VACUUM FULL。

VACUUM的执行会有大量的I/O交换，这回导致其他的Session性能下降。Postgresql中存在一些配置参数通过修改参数来影响后台vacuuming进程。

23.1.2 恢复磁盘空间

在Postgresql中，UPDATE和DELETE执行的数据行不会立即被移除老版本的行.这个方法的好处是多版本并发控制(MVCC)：这些行不能被删除如果对其他事务依然可见的话。但是最终，过期的或者已经被删除的行版本将不对任何的事务可见。此时被占用的磁盘空间必须被释放，以让新的数据重用可见。这就要执行VACUUM。

标准VACUUM删除表中的和索引中的行进而标注空间是可用的。虽然，这会释放空间但是不会被操作系统回收，除非在特殊的情况下一个Pages或者多个Pages完全的释放和能够容易的获取表的排它锁。在比较之下，VACUUM FULL会积极压缩表空间直到一个新版本。这会使表最小化，但是会消耗更长的时间。这也需要占用额外的表空间用作复制新表直到完成。

通常情况下，VACUUM已经可以满意日常VACUUMing的要求尽量避免使用VACUUM FULL。后台守护进程也不会尝试使用VACUUM FULL。在这种方法下，建议不要讲表保持在最小大小，但维持稳态的磁盘空间：每一个表占用的空间相当于最小空间加上使用VACUUMING后释放的空间。尽管VACUUM FULL可以压缩表，释放空间给操作系统，但是在表会持续增长的情况下没有太大的实际意义。因此，适度频繁的VACUUM比需要大量更新表的VACUUMFULL有优势。

有些管理员宁愿自己来调度执行vacuuming，，比如在负载低的时候来做所有这些事情。困难的是按照这个固定的工作调度时意外的需要执行更新操作，可能看见会增长，此时使用VACUUM FULL是有必要的。使用auttovacuum守护进程可以缓解这个问题，因为守护进程可以动态的反馈更新活动的情况。完全的禁止守护进程是不明智的发除非你能很好的控制负载。一种折中的方式是设置守护进程参数以便有大量的不常发生的大量更新操作，从而保证VACUUM能完成批量的工作。

对于那些没有使用autovacuum的情况，一种比较典型的做法是在负载低的情况下执行vacuum，从而来辅助高负载情况下执行vacuum开销大的情况。(有些情况是大量更新频繁甚至几分钟就需要更新)如果你有备份在集群中，不要忘记对其他的数据库也执行Vacuum。Vacuumdb命令可能更有用。

小技巧1：当有大量由于删除和更新导致的大量过期版本数据的情况下单纯使用Vacuum可能并不是很令人满意。如果你有这样一张表，你最好还是使用Vacuum Full，要么使用CLUSTER，要么使用ALTER TABLE等方法。因为这些命令会重写数据和索引，当然所有这些操作都是需要获取排它锁的。注意在执行这些操作是也会临时使用相同大小的磁盘空间，因为老的表阿和索引不能被清除直到操作完成。

小技巧2：如果你需要将一个数据量比较大的表删除全部的数据或者删除大量数据时，最好使用TRUNCATE命令，这样就不会产生多版本数据。无需执行VACUUM或者VACUUM FULL。

23.1.3. 更新执行计划统计信息

Postgresql数据库执行计划依赖统计信息表的内容以此信息用来保证一个好的执行计划。统计信息是用过ANALYZE命令来实现的，可以单独执行也可以在VACUUM是被执行。精确完整的统计信息对数据库很重要，不然会导致数据库性能低下。

如果AutoVACUUM守护进程开启的话，每当表被修改那么ANALYZE命令就会被自动激发执行。但是，有时候数据库管理员宁愿手动执行，特别是当update操作不影响插入操作时。守护进程会在insert或者update之后严格的执行ANALYZE，但并不意味着有用的统计信息被修改。

与使用VACUUM来释放空间一样，频繁的更新统计信息对会大量更新的表的作用比很少更新的表作用大。但是即使大量更新的表也没有必要去更新统计信息，因为更新的数据其实不影响表数据的统计分布。一个简单的法则是考虑表中字段最大或者最小值是否改变。例如：行的时间戳字段被更新其值会不断的增加和更新；这样的字段需要不断的更新统计信息，再者，一个字段的包含了一个能访问网点的URL，这个URL字段可能会不断变化但是其统计分布变化的非常缓慢。

可以特指一个表或者表上的字段来执行analyze，这种更新统计信息的方法是高效的及时的。事实上，不管怎么样，通常最好是使用analyze在整个数据库上，因为这样更高效。Annlyze是使用随机抽样而不是去查看每一行。

小技巧1：尽管频繁按列绑定执行ANALYZE不是很有效，但是你可以发现通过调整ANALYZE收集统计信息等级等细节将是有价值的。广泛使用在where子句中的字段的直方图统计信息的精确度比其他字段的精确度要求要高。查看ALTER TABLE SETSTATISTICS或者在数据库中默认使用default_statistics_target的配置参数。

另外默认情况下，只有有限的信息对于选择性函数。但是如果创建了表达式索引并且执行函数，就可以收集有用的统计信息，这将会大大的改进执行计划的有用性当使用表达式索引时。

小技巧2：AUTOVACUUM的守护进程不会在有外键的表上执行ANALYZE命令，因为不确实什么时候会被使用。如果你想得到一个完整的统计信息在存在外键表，那么就手动执行吧。