事务与并发控制
事务可以理解为做一件事,数据库就是一件事要么做完,要么不做,不然这数据库给给人不可靠的感觉
正如解释事务具有四个重要特性: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插件可以实现在线重建表和索引。
实现原理:建表,导数据,建索引,接表名、删表