数据库多版本并发控制

数据库多版本并发控制

在一篇帖子中，看到一幅图片，我觉得基本诠释了什么是多版本并发控制，该图引用自https://www.cnblogs.com/aspirant/p/6920987.html，非原创：

多版本并发控制的定义：

所谓多版本并发控制，就是在数据表的每一行上面增加两个隐藏字段，一个是数据插入时的版本号，一个是数据删除时的版本号，这样给数据刚增加版本的控制，就成为数据库的多版本并发控制。

多版本并发控制的意义：

多版本并发控制的意义在于，可以实现数据库的非阻塞式读取。同时解决数据库脏读和不可重复读取的问题。

多版本并发控制下CRUD：

系统版本号：数据库每开启一个事务，系统版本号就加1
事务版本号：事务开启时的系统版本号
select：查询数据行的新增版本号小于等于当前事务版本号，同时，数据行的删除版本号要么大于当前事务号，要么为空。
update：检索到指定的行，将该行的删除版本号改为事务的版本号，同时新增加一行，该行的数据为修改后的数据，数据的新增版本号为当前事务的版本号，删除版本号设为空。
create：增加一行，数据的新增版本号为当前事务的版本号，删除版本号设为空。
delete：检索到该行，将该行的数据的删除版本号设置为当前的事务版本号。

mysql的innodb引擎算不上正真的MVCC

（一下内容引用自https://blog.youkuaiyun.com/xifeijian/article/details/45230053 ）
Innodb的实现算不上MVCC，因为并没有实现核心的多版本共存，undo log中的内容只是串行化的结果，记录了多个事务的过程，不属于多版本共存。但理想的MVCC是难以实现的，当事务仅修改一行记录使用理想的MVCC模式是没有问题的，可以通过比较版本号进行回滚；但当事务影响到多行数据时，理想的MVCC据无能为力了。

比如，如果Transaciton1执行理想的MVCC，修改Row1成功，而修改Row2失败，此时需要回滚Row1，但因为Row1没有被锁定，其数据可能又被Transaction2所修改，如果此时回滚Row1的内容，则会破坏Transaction2的修改结果，导致Transaction2违反ACID。

理想MVCC难以实现的根本原因在于企图通过乐观锁代替二段提交。修改两行数据，但为了保证其一致性，与修改两个分布式系统中的数据并无区别，而二段提交是目前这种场景保证一致性的唯一手段。二段提交的本质是锁定，乐观锁的本质是消除锁定，二者矛盾，故理想的MVCC难以真正在实际中被应用，Innodb只是借了MVCC这个名字，提供了读的非阻塞而已。