本文目录
针对PG使用多版本并发控制MVCC机制，所带来的空间膨胀问题，GBase 8c有什么解决方案
GBase 8c实现了undo机制，也就是可以在原位置更新数据。这带来的好处包括高性能：对插入、更新、删除等不同负载的业务性能以及资源使用表现相对均衡。相比append update引擎性能提升10%。运行平稳：性能运行平稳8小时，性能滚降值从13.8%降低至2.5%。高效存储：支持最大限度的原位更新， TPCC负载下平均节约空间15%~20%，undo空间统一分配，集中回收，复用效率更高，存储空间使用更加高效平稳。
MYSQL的事务隔离级别，MVCC，readView和版本链小结
MVCC(Mutil-Version Concurrency Control)，就是多版本并发控制。这种并发控制的方法，主要应用在RC和RR隔离级别的事务当中，利用执行select操作时，访问记录版本链，使得不同事物的读写，写读可以并发执行，提高系统性能。
Innodb 有两个隐藏字段 trx_id(事务id)和roll_pointer(回滚指针)。 transaction id ： innoDB里面每个事务有一个唯一的事务ID，叫作transaction id，它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。 roll_pointer ： 指向上一事务版本的指针。 版本链 ： 是一个单链表结构，对于同一行数据，每一个事务对其进行更新的时候都会产生一个新的版本，就会存储在这个链表当中。
一个存储事务id的列表。
readview的几个参数： m_ids:表示活跃事务id列表 min_trx_id:活跃事务中的最小事务id max_trx_id:已创建的最大事务id creator_trx_id:当前的事务id。 readview的生成时机： RC隔离级别：每次读取数据前，都生成一个readview； RR隔离级别：在第一次读取数据前，生成一个readview；
使用场景： , 说明100和150都是未提交的活跃事务, 再向前一个节点50不在活跃事务列表说明事务50已经提交, 所以事务200拷贝事务50并插入版本链最后, 且将200追加到readView活跃列表的最后一个元素
当我再次进行200号事务的查询或修改, 我需要读版本链的数据, 因为上一次操作已经在版本链做了200号节点, 因此我读的数据都是200号节点的数据, 这样就隔离了其他未提交的事务; 我的全部增删查改都在200号版本链上进行
以上两点都是基于隔离级别"读已提交"来进行说明的; 当mysql设置为"可重复读"时, 不同事务仍然是保存在版本链的不同节点上, 只不过新的事务创建的时候拷贝了当下的readView列表, 只要新事物不提交就一直使用这个拷贝的活跃列表; 假设此时100号数据提交了, 我在新事务执行了select 会去查活跃列表发现100号事务还是未提交状态, 因此读取到的还是50号事务提交的记录。
原子性，一致性，隔离性，持久性。
未提交读（read uncommitted）、提交读（read committed）、可重复读（repeatable read）、序列化读（serializable）
如何同时运行两个连接，连接H2数据库
查看数据可以通过MVCC=TRUE这样的方式，MVCC(Multi-Version Concurrent Control) 多版本并发控制模式，如不开启，好像则只能单链接数据库文件。jdbc.url=jdbc:h3:mem:h3
