07-PG清理——VACUUM

PostgreSQL 清理（一） VACUUM

1.PG MVCC实现

PG采用了和其他RDBMS完全不同的方式实现了多版本并发控制（简称MVCC）。在Oracle或InnoDB中，当我们删除或更新一条记录时，数据库会将删除的记录放到undo段中，undo段中的记录前镜像保证了数据库的一致性。这种实现方式经常会遇到两个问题，一个是在Oracle 常见的01555错误，遇到这种错误DBA一般会调大undo_retention参数或增大UNDO表空间；另一个问题就是delete大量数据时可能会造成其他事务查询效率降低，而回滚delete操作更是让DBA头疼。而PG采用了完全不同的方法来管理undo数据，或者称为旧版本数据。

PG会将旧版本数据和最新版本数据放在表内，可以理解为PG将ubdo数据由Oracle的集中管理优化为各个表自己分散管理。在PG中每个行都有两个事务ID，一个表示该条记录被插入时的事务ID（xmin），另一个表示该条记录删除时的事务ID(xmax)，PG根据行记录中的这两个事务ID和标志位，来确定此条记录对当前事务是否可见。

2.VACUUM

正如上面所说，每一条记录虽然被删除了，但仍然占用了一些空间，这种记录被称为死亡元组。产生这些死元组的事务结束，就不再需要死亡元组。因此，PostgreSQL在这样的表上运行vacuum。vacuum回收这些死元组所占用的存储空间。这些死元组占用的空间可以称为膨胀(Bloat)。vacuum扫描页面中的死元组，并将它们标记到空闲空间映射(FSM)。除了hash索引外，每个表和索引都有一个空闲空间映射存储在一个名为<relation_oid>_fsm的单独文件中。

3.数据库视界

在PG中有一个视界的概念，每个事务有自己的事务视界，即此事务使用快照的下限，也就是创建快照时（此事务开始时）活动的最老的事务ID，超出事务视界的所有行版本都可以被此事务看见。

test=# begin;
BEGIN
#查看事务视界
test=*# SELECT backend_xmin FROM pg_stat_activity
test-*# WHERE pid = pg_backend_pid();
 backend_xmin 
--------------
          763
(1 row)
#查看此事务使用的快照
test=*# SELECT pg_current_snapshot();
 pg_current_snapshot 
---------------------
 763:763:
(1 row)

test=*# commit;

按照上述方法，我们可以定义数据库的视界，数据库的视界为该数据库中所有事务的最老事务的xmin，超出数据库视界的所有“死”元组永远不可能被数据库的其他事务访问，这些元组可以被安全的清理（vacuum），vacuum的清理依据就是数据库视界，我们可以通过下面的查询确定test库的视界

test=# select min(backend_xmin::varchar::int) from pg_stat_activity where datname='test';
 min 
-----
 763
(1 row)

PG中视界概念灵感来源于物理学中黑洞的视界

实验：数据库视界

#创建测试数据
 create table t1(id int,name varchar(10));
 insert into t1 values(1,'aaa');
 insert into t1 values(2,'bbb');
 insert into t1 values(3,'ccc');
 insert into t1 values(4,'ddd');
#查看元组信息
test=# select * from heap_page('t1',0);
 ctid  | state  | xmin  | xmax 
-------+--------+-------+------
 (0,1) | normal | 764 c | 0 a
 (0,2) | normal | 765 c | 0 a
 (0,3) | normal | 766 c | 0 a
 (0,4) | normal | 767 c | 0 a
(