innodb mvcc实现机制
多版本并发控制
大部分的MySQL的存储 引擎，比如InnoDB，Falcon，以及PBXT并不是简简单单的使用行锁机制。它们都使用了行锁结合一种提高并发的技术，被称为MVCC（多版本并 发控制）。MVCC并不单单应用在MySQL中，其他的数据库如Oracle,PostgreSQL,以及其他数据库也使用这个技术。
MVCC避免了许多需要加锁的情形以及降低消耗。这取决于它实现的方式，它允许非阻塞读取，在写的操作的时候阻塞必要的记录。
MVCC保存了某一时刻数据的一个快照。意思就是无论事物运行了多久，它们都能看到一致的数据。也就是说在相同的时间下，不同的事物看相同表的数据是不同的。如果你从来没有这方面的经验，可能说这些有点令人困惑。但是在以后这个会很容易理解和熟悉的。
每个存储引擎实现MVCC方式都是不同的。有许多种包含了乐观（optimistic）和悲观（pessimistic）的并发控制。我们用简单的InnoDb的行为来举例说明MVCC工作方式。
说道事物，我们必须了解一点基础知识：
一、基础知识
事务： 事务是一组原子性sql查询语句，被当作一个工作单元。若mysql对改事务单元内的所有sql语句都正常的执行完，则事务操作视为成功，所有的sql语句才对数据生效，若sql中任意不能执行或出错则事务操作失败，所有对数据的操作则无效(通过回滚恢复数据)。事务有四个属性： 1、原子性：事务被认为不可分的一个工作单元，要么全部正常执行，要么全部不执行。 2、一致性：事务操作对数据库总是从一种一致性的状态转换成另外一种一致性状态。 3、隔离性：一个事务的操作结果在内部一致，可见，而对除自己以外的事务是不可见的。 4、永久性：事务在未提交前数据一般情况下可以回滚恢复数据，一旦提交(commit)数据的改变则变成永久(当然用update肯定还能修改)。 ps:MYSAM 引擎的数据库不支持事务，所以事务最好不要对混合引擎(如INNODB 、MYISAM)操作，若能正常运行且是你想要的最好，否则事务中对非支持事务表的操作是不能回滚恢复的。 读锁： 也叫共享锁、S锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S 锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。 写锁： 又称排他锁、X锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。 表锁：操作对象是数据表。Mysql大多数锁策略都支持(常见mysql innodb)，是系统开销最低但并发性最低的一个锁策略。事务t对整个表加读锁，则其他事务可读不可写，若加写锁，则其他事务增删改都不行。 行级锁：操作对象是数据表中的一行。是MVCC技术用的比较多的，但在MYISAM用不了，行级锁用mysql的储存引擎实现而不是mysql服务器。但行级锁对系统开销较大，处理高并发较好。 MVCC：多版本并发控制(MVCC,Multiversion Currency Control)。一般情况下，事务性储存引擎不是只使用表锁，行加锁的处理数据，而是结合了MVCC机制，以处理更多的并发问题。Mvcc处理高并发能力最强，但系统开销比最大(较表锁、行级锁)，这是最求高并发付出的代价。 Autocommit：是mysql一个系统变量，默认情况下autocommit=1表示mysql把没一条sql语句自动的提交，而不用commit语句。所以，当要开启事务操作时，要把autocommit设为0，可以通过“set session autocommit=0; ”来设置
二、MVCC实现原理以及例化理解(包含些测试以便理解)
第一：先看看网络上几乎全部一样的理解，包括《高性能mysql第二版(中文版)》也如此说明，这样是很容易理解。但笔者觉得2个地方不妥，先看内容，在后面笔者会给出不妥地方用(1、2…)加粗标志出来，且给出测试证明。 Ps：这些只是外部看来的理解层面，深层次在第三点讲解 ------------------------------------------ InnoDB实现MVCC的方法是，它存储了每一行的两个(1)额外的隐藏字段，这两个隐藏字段分别记录了行的创建的时间和删除的时间。在每个事件发生的时候，每行存储版本号，而不是存储事件实际发生的时间。每次事物的开始这个版本号都会增加。自记录时间开始，每个事物都会保存记录的系统版本号。依照事物的 版本来检查每行的版本号。在事物隔离级别为可重复读的情况下，来看看怎样应用它。 SELECT Innodb检查没行数据，确保他们符合两个标准： 1、InnoDB只查找版本早于当前事务版本的数据行(也就是数据行的版本必须小于等于事务的版本)，这确保当前事务读取的行都是事务之前已经存在的，或者是由当前事务创建或修改的行 2、行的删除操作的版本一定是未定义的或者大于当前事务的版本号。确定了当前事务开始之前，行没有被删除(2) 符合了以上两点则返回查询结果。 INSERT InnoDB为每个新增行记录当前系统版本号作为创建ID。 DELETE InnoDB为每个删除行的记录当前系统版本号作为行的删除ID。 UPDATE InnoDB复制了一行。这个新行的版本号使用了系统版本号。它也把系统版本号作为了删除行的版本。 ---------------------------------------------- (1) 不是两个，是三个。 1DB_TRX_ID：一个6byte的标识，每处理一个事务，其值自动+1，上述说到的“创建时间”和“删除时间”记录的就是这个DB_TRX_ID的值，如insert、update、delete操作时，删除操作用1个bit表示。 DB_TRX_ID是最重要的一个，可以通过语句“show engine innodb status”来查找，如下： ----------------------------------------- …… TRANSACTIONS ------------ Trx id counter 0 430621 Purge done for trx\'s n:o < 0 430136 undo n:o < 0 0 History list length 7 …… ------------------------------------------ 2DB_ROLL_PTR: 大小是7byte,指向写到rollback segment(回滚段)的一条undo log记录(update操作的话，记录update前的ROW值) 3DB_ROW_ID: 大小是6byte,该值随新行插入单调增加，当由innodb自动产生聚集索引时，聚集索引包括这个DB_ROW_ID的值，不然的话聚集索引中不包括这个值. 这个用于索引当中 (2) 这里的不是真正的删除数据，而是标志出来的删除。真正意义的删除是在commit的时候。网上的说法很容易让读者误解 (3) 这点上面没有标注，在insert操作时 “创建时间”=DB_ROW_ID，这时，“删除时间 ”是未定义的；在update时，复制新增行的“创建时间”=DB_ROW_ID，删除时间未定义，旧数据行“创建时间”不变，删除时间=该事务的DB_ROW_ID；delete操作，相应数据行的“创建时间”不变，删除时间=该事务的DB_ROW_ID；select操作对两者都不修改，只读相应的数据 第二、下面用图形化形式表示MVCC如何处理select、insert、delete、update 有两个事务A、B 假设开始时间顺序ABCD，且DB_TRX_ID满足以下情况 A. DB_TRX_ID = 2010 B. DB_TRX_ID = 2011 C. DB_TRX_ID = 2012 D. DB_TRX_ID = 2013
注意：
1、B. DB_TRX_ID> A. DB_TRX_ID是因为DB_TRX_ID的值是系统版本号的值，系统版本号是自动增加的，所以DB_TRX_ID也是自动增加。但是会出现这种情况，假如A事务开始后B事务开始前有一个insert操作插入一行数据(没有bengin、comint)，则B. DB_TRX_ID= A. DB_TRX_ID+1+1 ，并不符合不是说系统版本号增量为1。
InnoDB实现MVCC的方法是，它存储了每一行的两个额外的隐藏字段，这两个隐藏字段分别记录了行的创建的时间和删除的时间。在每个事件发生的时 候，每行存储版本号，而不是存储事件实际发生的时间。每次事物的开始这个版本号都会增加。自记录时间开始，每个事物都会保存记录的系统版本号。依照事物的 版本来检查每行的版本号。在事物隔离级别为可重复读的情况下，来看看怎样应用它。
SELECT
InnoDB检查每行，要确定它符合两个标准。
InnoDB必须知道行的版本号，这个行的版本号至少要和事物版本号一样的老。（也就是是说它的版本号可能少于或者和事物版本号相同）。这个既能确定事物开始之前行是存在的，也能确定事物创建或修改了这行。
行的删除操作的版本一定是未定义的或者大于事物的版本号。确定了事物开始之前，行没有被删除。
符合了以上两点。会返回查询结果。
INSERT
InnoDB记录了当前新增行的系统版本号。
DELETE
InnoDB记录的删除行的系统版本号作为行的删除ID。
UPDATE
InnoDB复制了一行。这个新行的版本号使用了系统版本号。它也把系统版本号作为了删除行的版本。
所有其他记录的结果保存是，从未获得锁的查询。这样它们查询的数据就会尽可能的快。要确定查询行要遵循这些标准。缺点是存储引擎要为每一行存储更多的数据，检查行的时候要做更多的处理以及其他内部的一些操作。
MVCC只能在可重复读和可提交读的隔离级别下生效。不可提交读不能使用它的原因是不能读取符合事物版本的行版本。它们总是读取最新的行版本。可序列化不能使用MVCC的原因是，它总是要锁定行。
下面的表说明了在MySQL中不同锁的模式以及并发级别。
| 锁的策略 | 并发性 | 开销 | 引擎 |
| 表 | 最低 | 最低 | MyISAM,Merge,Memory |
| 行 | 高 | 高 | NDB Cluster |
| 行和MVCC | 最高 | 最高 | InnoDB,Falcon,PBXT,solidD |
在并发读写数据库时，读操作可能会不一致的数据（脏读）。为了避免这种情况，需要实现数据库的并发访问控制，最简单的方式就是加锁访问。由于，加锁会将读写操作串行化，所以不会出现不一致的状态。但是，读操作会被写操作阻塞，大幅降低读性能。在Java concurrent包中，有copyonwrite系列的类，专门用于优化读远大于写的情况。而其优化的手段就是，在进行写操作时，将数据copy一份，不会影响原有数据，然后进行修改，修改完成后原子替换掉旧的数据，而读操作只会读取原有数据。通过这种方式实现写操作不会阻塞读操作，从而优化读效率。而写操作之间是要互斥的，并且每次写操作都会有一次copy，所以只适合读大于写的情况。
再啰嗦几句，MVCC的原理与copyonwrite类似，每个读操作会看到一个一致性的snapshot，并且可以实现非阻塞的读。MVCC允许数据具有多个版本，这个版本可以是时间戳或者是全局递增的事务ID，在同一个时间点，不同的事务看到的数据是不同的。
实现原理：
------------------------------------------------------------------------------------------> 时间轴 |-------R(T1)-----| |-----------U(T2)-----------| 如上图，假设有两个并发操作R(T1)和U(T2)，T1和T2是事务ID，T1小于T2，系统中包含数据a = 1(T1)，R和W的操作如下： R：read a (T1) U：a = 2 (T2) R（读操作）的版本T1表示要读取数据的版本，而之后写操作才会更新版本，读操作不会。在时间轴上，R晚于U，而由于U在R开始之后提交，所以对于R是不可见的。所以，R只会读取T1版本的数据，即a = 1。 由于在update操作提交之前，不能影响已有数据的一致性，所以不会改变旧的数据，update操作会被拆分成insert + delete。需要标记删除旧的数据，insert新的数据。只有update提交之后，才会影响后续的读操作。而对于读操作而且，只能读到在其之前的所有的写操作，正在执行中的写操作对其是不可见的。 上面说了一堆的虚的理论，下面来点干活，看一下MySQL的innodb引擎是如何实现MVCC的。innodb会为每一行添加两个字段，分别表示该行创建的版本和删除的版本，填入的是事务的版本号，这个版本号随着事务的创建不断递增。在repeated read的隔离级别（事务的隔离级别请看这篇文章）下，具体各种数据库操作的实现： select：满足以下两个条件innodb会返回该行数据：（1）该行的创建版本号小于等于当前版本号，用于保证在select操作之前所有的操作已经执行落地。（2）该行的删除版本号大于当前版本或者为空。删除版本号大于当前版本意味着有一个并发事务将该行删除了。 insert：将新插入的行的创建版本号设置为当前系统的版本号。 delete：将要删除的行的删除版本号设置为当前系统的版本号。 update：不执行原地update，而是转换成insert + delete。将旧行的删除版本号设置为当前版本号，并将新行insert同时设置创建版本号为当前版本号。 其中，写操作（insert、delete和update）执行时，需要将系统版本号递增。 由于旧数据并不真正的删除，所以必须对这些数据进行清理，innodb会开启一个后台线程执行清理工作，具体的规则是将删除版本号小于当前系统版本的行删除，这个过程叫做purge。 通过MVCC很好的实现了事务的隔离性，可以达到repeated read级别，要实现serializable还必须加锁。
