转自
http://blog.csdn.net/sofia1217/article/details/50778906 关于MVCC浅析，有些难度
http://xuebinbin212.blog.163.com/blog/static/1121673762013921111828684/
行的更新过程
下面演示下事务对某行记录的更新过程：
1. 初始数据行
F1～F6是某行列的名字，1～6是其对应的数据。后面三个隐含字段分别对应该行的事务号和回滚指针，假如这条数据是刚INSERT的，可以认为ID为1，其他两个字段为空。
2.事务1更改该行的各字段的值
当事务1更改该行的值时，会进行如下操作：
- 用排他锁锁定该行
- 记录redo log
- 把该行修改前的值Copy到undo log，即上图中下面的行
- 修改当前行的值，填写事务编号，使回滚指针指向undo log中的修改前的行
3.事务2修改该行的值
与事务1相同，此时undo log，中有有两行记录，并且通过回滚指针连在一起。
因此，如果undo log一直不删除，则会通过当前记录的回滚指针回溯到该行创建时的初始内容，所幸的时在Innodb中存在purge线程，它会查询那些比现在最老的活动事务还早的undo log，并删除它们，从而保证undo log文件不至于无限增长。
-Undo+Redo
事务的简化过程
假设有A、B两个数据，值分别为1,2.
A.事务开始.
B.记录A=1到undolog.
C.修改A=3.
D.记录A=3到redolog.
E.记录B=2到undolog.
F.修改B=4.
G.记录B=4到redolog.
H.将redolog写入磁盘。
I.事务提交
-Undo+Redo
事务的特点
A.为了保证持久性，必须在事务提交前将，RedoLog持久化。
B.数据不需要在事务提交前写入磁盘，而是缓存在内存中。
C.RedoLog保证事务的持久性。
D.UndoLog保证事务的原子性。
E.有一个隐含的特点，数据必须要晚于redolog写入持久存
REDO LOG和UNDO LOG增加3个字段：隐藏ID,事务ID,回滚指针ID
MVCC增加了2个字段:行的创建时间,删除时间