MySQL的并发控制MVCC

看下如下2个demo，关闭了自动事务，select和update语句会自动给users表加上S锁(共享锁)和X锁(排它锁)。S锁和X锁是互斥的，按理说先执行的事务未commit或者rollback之前，另一个事务是无法对users表加互斥锁进行操作的，但是这里两个demo却可以正常执行。
demo1：

transaction1:
      set session autocommit=off;
      update users set lastUpdate=now() where id =1;//加x锁，使用记录锁Record锁
transaction2:
      select *  from users where id > 1;//未锁住，可以执行是正常的。
      select * from users where id= 1;//按理说条数据行应该锁住，不能加S锁才对啊，为什么可以加S锁呢？

demo2：

transaction1:
     begin
      select * from users where id= 1;
transaction2:
      update users set lastUpdate=now() where id =1;
 transaction1:
      select * from users where id= 1;

一 MVCC
MVCC (Mutil-Version Concurrency ControL)，多版本并发控制。并发访问(read/write)数据库时，对正在事务内处理的数据做多版本的管理，避免因写操作堵塞而引发读操作的并发问题。

建一张简单的表，有如下三个字段，我们看到的结构如下。

   主键        姓名         年龄
---------------------------------
|  id     |    name     |  age  |
----------------------------------
|         |             |        |
----------------------------------

实际上MySQL底层还会帮助我们多建立2个字段:trx_id 和 roll_pointer，它们的取值均来自于全局事务ID生成器。
trx_id 用于记录

   主键        姓名         年龄     数据行版本号     删除版本号
-------------------------------------------------------------
|  id     |    name     |  age  |    trx_id    | roll_pointer
-----------------------------------------------------------
|         |             |       |              |
------------------------------------------------------------

我们对表插入数据：

begin;//自动获取当前的全局事务ID，假设这里ID=1
insert into users (name,age) values('tom',18);
insert into users (name,age) values('lily',18);
commit;

那么sql执行后的实际上的表内容如下：

   主键        姓名         年龄     数据行版本号   删除版本号
-------------------------------------------------------------
|  id     |    name     |  age  |    trx_id    | roll_pointer
-----------------------------------------------------------
|   1     |    tom      |  18   |       1      |    null
------------------------------------------------------------
|   2     |    lily     |  18   |       1      |    null
------------------------------------------------------------

删除数据

begin;//自动获取当前的全局事务ID，假设这里ID=22
delete users where id=2；
commit;

那么sql执行后的实际上的表内容如下：

   主键        姓名         年龄     数据行版本号   删除版本号
-------------------------------------------------------------
|  id     |    name     |  age  |    trx_id    | roll_pointer
-----------------------------------------------------------
|   1     |    tom      |  18   |       1      |    null
------------------------------------------------------------
|   2     |    lily     |  18   |       1      |     22
------------------------------------------------------------

看下修改操作：

begin;//自动获取当前的全局事务ID，假设这里ID=33
update users set age =20 where id = 1；
commit;

那么sql执行后的实际上的表内容如下：

   主键        姓名         年龄     数据行版本号   删除版本号
-------------------------------------------------------------
|  id     |    name     |  age  |    trx_id    | roll_pointer
-----------------------------------------------------------
|   1     |    tom      |  18   |       1      |    33
------------------------------------------------------------
|   2     |    lily     |  18   |       1      |    22
------------------------------------------------------------
|   1     |    tom      |  19   |      33      |    null
------------------------------------------------------------

update过程相当于如下两步：
1.将命中的数据行复制一份修改，包括业务数据age=19和trx_id=33
2.原来的数据roll_pointer标记为当前事务ID33。

基于前面的步骤，看下查询操作。

begin;//自动获取当前的全局事务ID，假设这里ID=44
select * from users；
commit;

查询规则：
1.查找数据行版本号早于当前事务版本的数据行，即版本号小于当前事务id的数据行。
这样可以保证当前事务读取的数据行，要么是事务开始前已经存在的，要么是事务自身插入后者修改过的。
2.查找删除版本号要么为null，要么要么大于当前事务版本号的数据行。
这样可以保证数据行在事务开启前没有被删除。
根据规则1，三条记录都符合，根据规则2只有第三条数据符合，查询结果如下：

   主键        姓名         年龄     数据行版本号   删除版本号
-------------------------------------------------------------
|  id     |    name     |  age  |    trx_id    | roll_pointer
-----------------------------------------------------------
|   1     |    tom      |  19   |      33      |    null
------------------------------------------------------------

UndoLog
事务开始之前，首先将命中的数据备份到一个undolog中。undolog是为了实现事务原子性而产生的，当事务过程中出现了异常或者执行了rollback，就可以利用undolog中的备份将数据恢复到事务开始之前的状态。

InnoDB存储引擎利用undolog中的备份数据作为快照，供其他并发事务进行读操作。

快照读：
sql读取的数据是快照版本，也就是历史版本，普通的select就是快照读，InnoDB快照读由cache + undo两部分组成。快照读通过MVCC解决幻读问题。

当前读：
sql读取的数据是最新版本，UPDATE,DELETE,INSERT,SELECT …LOCK IN SHAR MODE,SELECT … FOR UPDATE都是当前读。通过临键锁NEXT-KEY锁机制解决幻读问题。

Redo log
事务操作数据时，将最新的数据备份到redo log中。redo log是为了实现事务的持久性而出现的产物。