mysql一致性非锁定读和mvcc_MySQL——一致性非锁定读(快照读)&MVCC

MySQL——一致性非锁定读(快照读)

MySQL数据库中读分为一致性非锁定读、一致性锁定读

一致性非锁定读(快照读)，普通的SELECT，通过多版本并发控制(MVCC)实现。

一致性锁定读(当前读)，SELECT ... FOR UPDATE/SELECT ... LOCK IN SHARE MODE/INSERT/UPDATE/DELETE，通过锁实现。

本文主要介绍一下一致性非锁定读，简单看一下2个场景：

-- 创建表tx

create table t (id int auto_increment,name varchar(10),primary key(id)) engine=innodb;

-- 写入数据

insert into t(name) values ('a');

场景一

session1

session2

查看事务隔离级别

select @@session.tx_isolation;

select @@session.tx_isolation;

查看数据

select * from t where id=1;

select * from t where id=1;

开启事务

begin;

begin;

会话1更新数据

update t set name='b' where id=1;

查看数据

select * from t where id=1;

select * from t where id=1;

会话1事务提交

commit;

会话2查看数据

select * from t where id=1;

会话2事务提交

commit;

场景二

session1

session2

查看事务隔离级别

select @@session.tx_isolation;

select @@session.tx_isolation;

查看数据

select * from t where id=1;

select * from t where id=1;

开启事务

begin;

begin;

会话1更新数据

update t set name='c' where id=1;

查看数据

select * from t where id=1;

会话1事务提交

commit;

会话2查看数据

select * from t where id=1;

会话2事务提交

commit;

场景一、二session1 分别对数据进行修改，事务隔离级别为可重复读(Repeatable read)；session2进行读取，场景二读取到了session1修改的数据;

是不是有点困惑？这就是所谓的MySQL一致性非锁定读，通过MVCC实现，细看场景一、二的不同，发现场景二session2在事务开启之后session1事务提交之前从未读取数据，这就是场景一、二结果不一样的原因(即数据版本的选取)。

一致性非锁定读是指InnoDB存储引擎通过多版本控制的方式来读取当前执行时间数据库中行的数据。如果读取的行正在执行DELETE或UPDATE操作，此时的读取操作不会因此去等待行上的锁释放。相反地，InnoDB存储引擎会去读取行的一个快照数据。

一致性非锁定读之所以成为非锁定读，因为不需要等待访问数据行的X锁的释放。快照数据是指该行数据的之前版本，改实现通过undo log完成。而undo是用来事务回滚的数据，因此快照数据本身没有额外的开销；此外快照数据不需要上锁，因为没有事务需要对历史数据进行修改操作。

一致性非锁定读机制极大的提高了数据库的并发性。在InnoDB存储引擎的默认设置下，这个默认的读取方式，即读取不会占用和等待表上的锁(SELECT ... FOR UPDATE/SELECT ... LOCK IN SHARE MODE除外)；一致性行非锁定读，用到到数据的之前的历史版本，可能会有多个历史版本，由此带来的并发控制，就是大名鼎鼎的多版本并发控制(MVCC)。

因为MYSQL数据库InnoDB存储引擎支持4中事务隔离级别，并不是每个事务隔离级别都采用一致性非锁定读。 在事务隔离级别已提交读(Read committed)、可重复读(Repeatable read InnoDB存储引擎默认的事务隔离级别)下，InnoDB存储引擎采用一致性非锁定读。

已提交读(Read committed)：每次普通的SELECT(非SELECT ... FOR UPDATE/SELECT ... LOCK IN SHARE MODE)都会读取数据的最新行版本(每次创建最新快照read view)。

可重复读(Repeatable read)：事务开启后第一次普通的SELECT(非SELECT ... FOR UPDATE/SELECT ... LOCK IN SHARE MODE)读取最新行版本(第一次创建快照，以后沿用read view)。 对于Innodb存储引擎的聚集索引即数据行存在2个隐藏的列trx_id事务id、roll_pointer回滚指针，trx_id用来一致性非锁定读判断数据是否可见，roll_pointer用于事务回滚(指向数据的上一个版本)；undo log中存在数据的版本链。

对于ReadView的实现：ReadView创建是根据当前活跃事务的列表，生成一个ReadView数据结构，包含当前所有活跃的事务id的ids集合、maxId最大事务id、minId最小事务id;

当读取数据时，数据行的事务id为trx_id

trx_id大于ReadView的maxId，则表示此trx_id的事务在生成ReadView之后开启的，数据的当前版本不可见

trx_id小于ReadView的minId，则表示此trx_id的事务在生成ReadView之前开启并提交的，数据的当前版本可见

trx_id处于minId与maxId之间的，需判断trx_id是否在ids里，在则数据的当前版本不可见，不在则数据的当前版本可见

上面简述了ReadView的原理和在事务隔离级别已提交读(Read committed)、可重复读(Repeatable read)的生成策略；接下来回顾一下本文开始的场景；

场景一，session2的事务隔离级别为可重复读，ReadView在第一次SELECT时创建，此时session1的事务已开启且尚未提交处于活跃状态；ReadView中ids含session1的trx_id，在之后读取的时复用ReadView(ids含session1的trx_id)，即使session1的事务提交后，session1修改的数据仍不可见。

场景一，session2的事务隔离级别为可重复读，ReadView在第一次SELECT时创建，此时session1的事务已提交；ReadView中ids不含session1的trx_id，session1修改的数据可见。

trx_id事务id，trx_id的生成时机、策略

-- MySQL查看当前事务的trx_id

SELECT tx.trx_id FROM information_schema.innodb_trx tx WHERE tx.trx_mysql_thread_id = connection_id()

通过演示可知事务trx_id：

trx_id全局唯一，递增

事务trx_id的在一致性锁定读(当前读)，SELECT ... FOR UPDATE/SELECT ... LOCK IN SHARE MODE/INSERT/UPDATE/DELETE时生成，且每个事务只有一个；对于一致性非锁定读(快照读)，普通的SELECT，若当事务尚未分配trx_id会生成一个伪trx_id(只读事务max_trx_id 2^48=421982752402168)(不涉及对数据的增删改)，若当前事务已经分配trx_id则复用

上面介绍了trx_id，以便于理解Mysql数据库InnoDB存储引擎一致性非锁定读的ReadView。

本文简单简单描述了一下MySQ InnoDB存储引擎的一致性非锁定读以及实现原理MVCC，因本人能力有限，如有不妥之处请多多指教。