MySQL的MVCC与其它锁的区别

多版本并发控制（MVCC），是一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。 这样在读操作不用阻塞写操作，写操作不用阻塞读操作的同时，避免了脏读和不可重复读。不仅是MySQL，包括Oracle、PostgreSQL等其他数据库系统也都实现了MVCC，但各自的实现机制不尽相同。

MVCC与乐观锁和悲观锁：

悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但开销很大，在SELECT ... FOR UPDATE 到commit中，行数据都会被锁定。被锁定的行数据在另一个事务中查询会被阻塞。

注意：使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认Row-Level Lock，所以只有「明确」地指定主键，MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。当按主键查询无数据时，不锁定。

set autocommit=0;　　
//设置完autocommit后，我们就可以执行我们的正常业务了。具体如下：
//0.开始事务
begin;/begin work;/start transaction; (三者选一就可以)
//1.查询出商品信息
select status from t_goods where id=1 for update;
//2.根据商品信息生成订单
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status为2
update t_goods set status=2;
//4.提交事务
commit;/commit work;

乐观锁，大多是基于数据版本（ Version ）记录机制实现(也可以是timestamp时间戳字段)。通过为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号等于数据库表当前版本号，则予以更新，否则认为是过期数据。乐观锁不会阻塞。

update t_goods 
        set status=#{status},name=#{name},version=version+1 
        where id=#{id} and version=#{version} 

乐观锁与悲观锁的区别在于悲观锁是先加锁再操作。乐观锁先操作，提交时才校验版本是否数据已经过期，如果过期则重试或者回滚。在并发冲突严重时候，乐观锁不如悲观锁。

MVCC是多版本并发，通过创建视图保证不同版本的并发执行。可能的问题是死锁，尤其是长事务中。

MVCC与锁定的优势：

可以认为MVCC是行级锁的一个变种，但是它在很多情况下避免了加锁操作。使用MVCC多版本并发控制比锁定模型的主要优点是在MVCC里， 对检索（读）数据的锁要求与写数据的锁要求不冲突， 所以读不会阻塞写，而写也从不阻塞读。

MVCC实现原理：

MVCC只能用于Innodb的读提交(RC)和可重复读(RR)隔离级别中。

InnoDB的行数据有多个版本，每个数据版本有自己的row trx_id，每个事务或者语句有自己的一致性视图。普通查询语句是一致性读，一致性读会根据row trx_id和一致性视图确定数据版本的可见性。

• 对于可重复读，查询只承认在事务启动前就已经提交完成的数据；
• 对于读提交，查询只承认在语句启动前就已经提交完成的数据；

而当前读，总是读取已经提交完成的最新版本。

在实现上， InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务ID。“活跃”指的就是，启动了但还没提交。可重复读就是依据数据的一致性视图和版本数组，以及undo log，依次执行到小于当前的版本号的视图，从而实现可重复读。

需要更新时，由于更新之前也会读取数据，即当前读，会读取到最新更新的数据。因为另一个事务已经提交的数据其版本号小于当前未提交的版本号。所以之前的提交对当前事务可见。

---