为什么会有表膨胀--多版本并发控制机制
多版本并发控制机制（MVCC）的原理在于，当它需要更改某块数据的时候，它不会直接去更改，而是会创建这份数据的新版本，在新版本进行更改，所以会存储多份版本，每个事务能看见哪一份版本的数据，由事务隔离级别控制。
MVCC引入了一个问题，如何消除老旧的、没有使用的无用数据（版本），目前主流上有3种处理实现方式：
来看看各种数据库的解决方式：
第一种：以Oracle为代表的，把旧版本数据放入UNDO，新数据放入REDO，然后更改数据。这种方式，旧版本的数据放入了UNDO，所以可以有效避免膨胀。
第二种，以SQL Server为代表的，把旧版本的数据写入专门的临时表空间，新数据写入日志，然后去更改数据。这种方式，旧版本的数据放入了专门的临时表空间，所以也可以有效地避免膨胀。
第三种，以PostgreSQL为代表的，把旧版本标示为无效，新数据写入日志，成功后把新版本的数据写入新的位置。这种实现机制是导致数据膨胀严重的一个重要原因，因为旧版本的数据虽然表示为无效状态，但是没被回收前还是占据存储空间。
PostgreSQL清理表膨胀之vacuum
PostgreSQL的表膨胀清理就需要依赖vacuum，vacuum的主要任务就是清理表和索引中不需要的数据（dead tuples），为新加入的数据清理出来空间。
vacuum的执行过程主要分为以下三步：
1. 清除dead tuples指向的index tuples
该过程中，vacuum会顺序扫描目标表，并构建一个dead tuples组成的list链表，该list链表会存储在maintenance_work_mem缓存中。然后vacuum根据dead tuples list移除dead tuples指向的index。
2. 移除dead tuples，更新VM和FSM
这里的移除dead tuples只是标记为可重用该空间，并没有真正物理删除。所以vacuum清理表后，表的实际空间并没有减小。dead tuples在做移除标记后，vacuum会重新排列剩余的元组以进行碎片化整理。然后，需要更新目标表的VM（可见性映射文件）和FSM（空闲空间映射文件）。
3. 更新统计信息和相关系统表
需要更新vacuum目标表的统计信息（以适应最新的查询优化）和相关系统表。
但是vacuum也有存在的问题。比如，vacuum完成清理工作后，那些空间并没有真正被释放给操作系统，只能被vacuum清理过的表和索引所利用。
PostgreSQL清理表膨胀之vacuum full
Vacuum Full和Vacuum最大的不同就是，Vacuum Full是物理删除dead tuples，并把释放的空间重新交给操作系统，所以在vacuum full后，表的大小会减小为实际的空间大小。其处理过程和vacuum大不相同，处理步骤如下：
1. vacuum full开始执行时，系统会先对目标创建一个AccessExclusiveLock ，不允许外界再进行访问（为后面拷贝做准备），然后创建一个表结构和目标表相同的新表。
2. 扫描目标表，把表中的live tuples 拷贝到新表中。
3. 删除目标表，在新表上，重新创建索引，更新VM， FSM以及统计信息，相关系统表等。
所以，vacuum full的本质是生成一个新的数据文件，然后把原有表的live tuples存放到该数据文件中。对比vacuum， vacuum full缺点就是在执行期间不能对表进行访问，由于需要往新表中导入live tuples数据，其执行效率也会很慢。优点是执行后，表空间只存放live tuples，没有冗余的dead tuples，在执行查询效率上会有所提高。
当然，vacuum full 也有存在的问题，在执行过程中，它会block所有对表的访问，不只是写操作，读操作也会全部block。很多情况下这是不可接受的，尤其是生产环境。
如何解决vacuum或vacuum full 带来的问题，社区也提供了pg_squeeze，pg_repack等工具，下回分解。