MVCC的特点是读写相互不壅闭，这就导致了一个特点就是所有的事务差异不大。
时间戳和可见性
只读事务在start-ts = commit-ts，写事务两者不一样，由于只读事务逻辑上等价于那个点，为串行化做了宽松的条件。
对于未提交的事务来说我们要一个最高位bit来表现，也就是可以预测性的先读，然后看看后续如果abort的话，我们就有对应的措施。同时uncommit的version上不能创建新的版本，厥后者需要abort。
hekton数据库也维护了一些事务的元数据
存储模子
把原来的复杂到delta storage，然后对attribute就地跟新
怎么确保快照可串行化
就像上面说的那样undo buffer那里存的是上一个最新commit的version,然后我们把当前事务和上一个version比较，重要通过where判断是否是有交集，如果有的话，就有可能出现幻读，为了可串行化，我们就要abort这个事务。
写写冲突，和rw成环
一些优化
由于version chain查找时，用的分支语句轻易造成cache miss，对于内存数据库来说，这个也很重要，所有我们将version vector做一个范围，淘汰这个cache miss
MVCC的一些不足
由于这个lecture的可串行化保证是MVCC+ OCC保证的。所以还要occ的不足
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
