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的不足
443
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
