MVCC机制

这里还只是一个大致的设计和运作思想，还需要深入mysql的实际redo log的内容去分析，和分解各种回滚情况，才能完全理解MVCC的实际物理运行机制。

多版本并发控制：
解决了脏读，脏写，不可重复度和幻读的问题。

每条数据都有两个隐藏的字段： 最近更新这条数据的事务id ， 指向上次更新这条数据的undo log的指针。

执行一个事务的时候会生成一个ReadView 这样的数据结构。

ReadView主要包含了4个比较重要的数据：

1. 当前未提交的所有事务id : m_ids
2. 创建ReadView的事务的id : creator_trx_id
3. 最小事务的id : min_trx_id
4. mysql（还没我有生成的）下一个要生成的事务id：max_trx_id

MVCC机制的过程：

当前有一条数据行(name='A')，最后被事务10进行操作，并且已经提交。

这时候有事务11，读取这个数据行，有事务15，修改和读取数据行。

事务11，读取name=A，发现当前数据行的事务id10，小于min_trx_id 11，说明，A这个值是事务11开启前就有的值，所以可以读取出来。

接着，事务12，修改这个数据行name=B，并且生成一个undo log记录。

这时候，事务11再去读取数据行name，发现=B，并且事务id=12。当前数据行最后操作的事务id 12 大于ReadView的最小事务id10 。所以这个B值是不可读取的，然后沿着找这个数据行的undo log的上一条记录， 上一条记录的name=A，事务id=10 ，小于最小事务id，所以A是可以读取的。 就再次读取到A，而不是读取到事务12修改过去后B 。

这样两个事务就隔离开来了互不影响，只读取ReadView产生之前的数据的值，避免了脏读脏写和不可重复读的问题。

幻读的问题，利用max_trx_id来判断解决。

事务20 ，发起查询，获取到一条数据行，当前数据行的事务id=15。

同时生成一个ReadView。(max_trx_id=21,min_trx_id=20)。

这时候，事务21，插入一条数据，那么新增的数据事务id=21。

这时候，事务20，再次执行查询，相同的查询条件可能会获取到两条数据。 但是，发现最后那条数据的事务id21 >= max_trx_id21。就可以指定，后面那条数据，在事务20执行之前，是不存在的，所以不能读取，只能读取事务id<20的数据。

这时候就避免了幻读。