一、为什么是VACUUM？
每当更新或删除PostgreSQL表中的行时，都会留下死元组。VACUUM摆脱了它们，以便空间可以重复使用。如果一个表没有被清理，它就会变得臃肿，这会浪费磁盘空间并减慢表的顺序扫描（以及索引扫描）。VACUUM还负责冻结表行，以避免在事务ID计数器环绕时出现问题，但这是另一回事。通常，您不必处理所有这些，因为PostgreSQL中内置的autovacuum 守护程序会为您完成这些工作。
二、问题
如果你的表变得臃肿，首先你需要检查的是 autovacuum 是否已处理它们：
SELECT schemaname, relname, n_live_tup, n_dead_tup, last_autovacuum
FROM pg_stat_all_tables
ORDER BY n_dead_tup
/ (n_live_tup
* current_setting('autovacuum_vacuum_scale_factor')::float8
+ current_setting('autovacuum_vacuum_threshold')::float8)
DESC
LIMIT 10;
如果你的臃肿的表没有出现在这里，n_dead_tup是0并且last_autovacuum是 NULL，你可能有统计信息收集器的问题。
如果臃肿的表就在顶部，但last_autovacuum为NULL，则您可能需要将autovacuum 配置为更积极，以便完成对表的处理。
但有时结果会如下所示：
schemaname | relname | n_live_tup | n_dead_tup | last_autovacuum
------------+--------------+------------+------------+---------------------
laurenz | vacme | 50000 | 50000 | 2018-02-22 13:20:16
pg_catalog | pg_attribute | 42 | 165 |
pg_catalog | pg_amop | 871 | 162 |
pg_catalog | pg_class | 9 | 31 |
pg_catalog | pg_type | 17 | 27 |
pg_catalog | pg_index | 5 | 15 |
pg_catalog | pg_depend | 9162 | 471 |
pg_catalog | pg_trigger | 0 | 12 |
pg_catalog | pg_proc | 183 | 16 |
pg_catalog | pg_shdepend | 7 | 6 |
(10 rows)
autovacuum最近在这里运行，但它没有释放死元组！
我们可以通过运行VACUUM (VERBOSE)来验证问：
test=> VACUUM (VERBOSE) vacme;
INFO: vacuuming "laurenz.vacme"
INFO: "vacme": found 0 removable, 100000 nonremovable row versions in
443 out of 443 pages
DETAIL: 50000 dead row versions cannot be removed yet,
oldest xmin: 22300
There were 0 unused item pointers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
三、为什么VACUUM不能删除死元组？
VACUUM只能删除不再需要的那些行版本（也称为“元组”）。如果删除事务的事务 ID（存储在xmax中）早于 PostgreSQL 数据库（或共享表的整个集群）中仍处于活动状态的最旧事务，则无法清除元组。
这个值（VACUUM上面输出中的 22300）称为“xmin 水平”。
在 PostgreSQL集群中，有三件事可以阻止这个xmin范围：
1、长时间运行的事务：
可以通过以下查询找到长时间运行的事务及其xmin值：
SELECT pid, datname, usename, state, backend_xmin
FROM pg_stat_activity
WHERE backend_xmin IS NOT NULL
ORDER BY age(backend_xmin) DESC;
可以使用该pg_terminate_backend()函数来终止阻止您的VACUUM.
2、废弃的Replication Slot：
复制槽是一种数据结构，保持从主库丢弃但仍需要由备用服务器赶上主要信息PostgreSQL服务器的数据。
如果复制延迟或备用服务器关闭，复制槽将阻
SELECT slot_name, slot_type, database, xmin
FROM pg_replication_slots
ORDER BY age(xmin) DESC;
使用该pg_drop_replication_slot()函数删除不再需要的复制槽。
注意：如果hot_standby_feedback = on. 对于逻辑复制存在类似的危险（无法回收元组），但只有系统目录受到影响。catalog_xmin在这种情况下检查列。
hot_standby_feedback参数之后备库会定期向主库通知最小活跃事务id（xmin）值，这样使得主库vacuum进程不会清理大于xmin值的事务。
3、孤立的准备运行的事务：
在两阶段提交期间，分布式事务首先用PREPARE语句准备，然后用COMMIT PREPARED语句提交。
一旦一个事务准备好，它就会一直“等待”直到它被提交或中止。它甚至必须在服务器重启后还需要保留下来！通常，事务不会长时间保持准备状态，但有时会出错，必须由管理员手动删除准备好的事务。
可以xmin使用以下查询找到所有准备好的交易及其价值：
SELECT gid, prepared, owner, database, transaction AS xmin
FROM pg_prepared_xacts
ORDER BY age(transaction) DESC;
使用ROLLBACK PREPAREDSQL 语句删除准备好的事务。
