事务与并发控制
事务可以理解为做一件事，数据库就是一件事要么做完，要么不做，不然这数据库给给人不可靠的感觉
正如解释事务具有四个重要特性：ACID（原子性，一致性，隔离性，持久性）
原子性，隔离性由mvcc控制。
幻读：可以看作不可重复读的另一种情况，B事务删除了数据或者插入数据，记录数不一致。
事务隔离级别
read uncommit 查询结果不可控
read commint (default)只能看到已提交事务
repeatable read：不可重复读不会发生
serializable 序列化，会导致严重等待表锁问题
pg的并发控制MVCC
排他锁：被枷锁对象只能有持锁人读/写，其他事务不行
共享锁：被加锁对象可以被持有人读取，不能修改，其他事务也可以在加共享锁
MVCC（多版本并发控制）
为什么要引入mvcc，锁协议一次只能执行一个事务，串行调度效率低。
mvcc呢就是把旧值保存在系统中，读不阻塞写，写不阻塞读，等到提交的时候才检验是否冲突，每一个写操作会创建一个新的版本，事务发出一个读操作会选择一个版本进行读取。
读取时，和版本号一起读取，更新时，把版本号一起更新。
版本号就是xid,每个事务分配一个递增的为int32类型的ID.
每行有四个事务可见性相关的隐藏列
xmin:创建该行数据的事务的xid
xmax:删除改行的xid
cmin:插入该行命令在事务中的命令序列标识
cmax:删除该行事务中命令序列标识
xmin中会包含xid,1、新事务没有提交，别的地方不可见2、xid大小。xid小的看不了xid大的。因为xid大的相对在"未来"
无论提交成功与否，xid始终递增的。
xmax
如果没有xmax，该行可见的
设置了回滚的xid，可见
设置了正在运行，没有commit和rollback的事务的xid,可见
设置为已提交的xid,不可见
Update的原理
可以通过xid变化可以得出，update是先删除在新插入数据
mvcc带来了哪些问题
表膨胀，因为新旧数据存储在同一个地方，如果大量更新会导致表膨胀
是由vacuum或者autovacuum将旧版本磁盘空间标为可用，但是没有办法把已经利用的磁盘空间释放出来。vacuum full 可以，但是会加锁阻塞
pg_repack插件可以实现在线重建表和索引。
实现原理：建表，导数据，建索引，接表名、删表