innodb mvcc
mvcc 多版本并发控制
在RR isolution 情况下 trx在启动的时候就拍了个快照。这个快照是基于整个数据库的。
其实这个快照并不是说拷贝整个数据库。并不是说要拷贝出这100个G的数据。
innodb里面每个trx有一个唯一的trxID 叫做trx id .在trx 开始的时候向innodb系统申请。严格按照申请顺序increment。
而每行数据都是有多个版本。每次trx 更新数据的时候，都会生成一个新的数据版本。并且把trx id赋给这个数据版本的trx id .记录为row trx_id .同时 旧的数据版本要保留。并且在新的数据版本中 能够直接拿到。
也就是说数据表中的一行记录 其实可能有多个版本。每个版本有自己的ID。
这里v1-v4 都是同一行数据的4个版本。当前最新的版本v4 k=4 是被trxid 40的事务更新。因此她的row trx_id = 25.
这里其实有undo的参与。在sql1 2 3的情况下。而且v1 v2 v3并不是物理情况下存在的。而是通过undo直接计算出来的。
在知道mvcc和row trxid 的概念下。上面说的innodb 的快照的概念。
按照RR的概念 当我这个事务启动的时候 能够看到所有已提交的事务。但是 这个事务执行的时候 其他事务的更新对他不可见。
因此 一个事务只需要在启动的时候说: 以我启动的时候为准。如果一个数据版本是我启动之前生成的，就认。如果是我启动之后生成的。就不认。我必须找到她的上一个版本。当然如果上一个也不可见 再往前找 找到认的为止。
从代码看实现 就是innodb 构建了一个Array 用来保存这个事务启动的时候。当前引擎正在活动的所有事务ID。活动的概念就是 启动了但是还
