我所了解的MySQL之四：事务、隔离级别及MVCC

mysql教程栏目介绍MySQL相干的事务、隔离级别及MVCC。

mysql教程栏目介绍MySQL相干的事务、隔离级别及MVCC。

yours=yours+50=150+50=200my=50yours=2007endendmy=50yours=200

两次转账后，终究的效果是我的账户余额为50元，你的账户余额为200元，这显然是不合错误的。

而要是在保障事务隔离性的状况下，就不会产生上面的状况，亏损的只是一定程度上的一致性。

1.4 耐久性（Durability）

事务的耐久性是指：事务在提交今后，它所做的修改就会被永恒保留到数据库。

在上述的转账场景中，耐久性就保障了在转账成功之后，我的账户余额为0，你的账户余额为200。

2. 主动提交与隐式提交

2.1 主动提交

在 MySQL 中，我们可以通过 begin 或 start transaction 来开启事务，通过 commit 来关闭事务，要是 SQL 语句中没有这两个下令，默许状况下每一条 SQL 都是一个独立的事务，在施行完成后主动提交。

比方：

update user set name='重塑' where id=1; 

假如我只施行这一条更新语句，在我关闭 MySQL 客户端然后从新打开一个新的客户端后，可以看到 user 表中的 name 字段值全酿成了「重塑」，这也印证了这条更新语句在施行后已被主动提交。

主动提交是 MySQL 的一个默许属性，可以通过 SHOW VARIABLES LIKE 'autocommit' 语句来查看，当它的值为 ON 时，就代表开启事务的主动提交。

mysql> SHOW VARIABLES LIKE 'autocommit';
+---------------+-------+| Variable_name | Value |
+---------------+-------+| autocommit    | ON    |
+---------------+-------+1 row in set (0.00 sec) 

我们可以通过 SET autocommit = OFF 来关闭事务的主动提交。

2.2 隐式提交

然而，即使我们已经将 autocommit 变量的值改为 OFF 关闭事务主动提交了，在施行某些 SQL 语句的时候，MySQL 还是会将事务主动提交掉，这被称为隐式提交。

会触发隐式提交的 SQL 语句有：

• DDL（Data definition language，数据定义说话），如 create, drop, alter, truncate
• 修改 MySQL 自带表数据的语句，如 create/drop user, grant, set password
• 在一个事务中，开启一个新的事务，会隐式提交上一个事务，如：

时刻	事务A	事务B
1	begin;
2	update user set name='重塑' where id=1;
3		select name from user where id=1;(N1)
4	begin;
5		select name from user where id=1;(N2)

在事务B中有两个查询语句N1和N2，施行的效果是N1=刺猬，N2=重塑，由此可以证实。

• 其他还有一些治理语句就纷歧一举例了，可自行baidu。

3. 隔离级别

事务的隔离级别规定了一个事务中所做的修改，在事务内和事务间的可见性。较初级另外隔离平常可以施行更高的并发，系统开销也更低。

在 SQL 规范中定义了四种事务的隔离级别，离别是读未提交（Read Uncommitted）、读已提交（Read Committed）、可反复读（Repeatable Read）、可串行化（Serializable）。

为了细致解释这四种隔离级别及它们各自产生的现象，假如有两个事务马上施行，施行内容如下表：

时刻	事务A	事务B
1	begin;
2		begin;
3		update user set name='重塑' where id=1;
4	select name from user where id=1;(N1)
5		commit;
6	select name from user where id=1;(N2)
7	commit;
8	select name from user where id=1;(N3)

在事务A和事务B施行的历程中，有三处查询 N1,N2,N3，在每个隔离级别下，它们值的状况是不一样的，下面离别计议。

3.1 读未提交（Read Uncommitted）

在读未提交的隔离级别下，事务中的修改，即使没有提交，对其他事务也都是可见的。

在上述场景中，若数据库的隔离级别为读未提交，因为事务A可以读取未提交事务B修改后的数据，即时刻3中事务B的修改对事务A可见，所以N1=重塑，N2=重塑，N3=重塑。

3.2 读已提交（Read Committed）

在读已提交的隔离级别下，事务中的修改只要在提交之后，才会对其他事务可见。

在上述场景中，若数据库的隔离级别为读已提交，因为事务A只能读取事务B提交后的数据，即时刻3中事务B的修改对事务A不成见，N2处的查询在事务B提交之后，故对事务A可见。所以N1=刺猬，N2=重塑，N3=重塑。

3.3 可反复读（Repeatable Read）

可反复读是 MySQL 的默许事务隔离级别。在可反复读的隔离级别下，一个事务中屡次查询雷同的记载，效果总是一致的。

在上述场景中，若数据库的隔离级别为可反复读，因为查询N1和N2在一个事务中，所以它们的值都是「刺猬」，而N3是在事务A提交今后再进行的查询，对事务B的修改是可见的，所以N3=重塑。

3.4 可串行化（Serializable）

在可串行化的隔离级别下，事务都是串行施行的，读会加读锁，写会加写锁，事务不会并发施行，所以也就不会产生异样状况。

在上述场景中，若数据库的隔离级别为可串行化，第一开启事务A，在开启事务B时被阻塞，直到事务A提交之后才会开启事务B，所以N1=刺猬，N2=刺猬。而N3处的查询会在事务B提交之后才施行（事务B先被阻塞，施行次序在N3查询语句以前），所以N3=重塑。

4. 隔离级别致使的题目

在不一样的事务隔离级别中，要是碰到事务并发施行，就会涌现许多题目，如脏读（Dirty Read）、不成反复读（Non-Repeatable Read）、幻读（Phantom Read）等，下面就离别用不一样的例子来细致注明这些题目。

4.1 脏读（Dirty Read）

脏读（Dirty Read）是指一个事务可以读取另一个未提交事务修改的数据。

看下面的案例，假如隔离级别为读未提交：

时刻	事务A	事务B
1	begin;
2		begin;
3		update user set name='重塑' where id=1;
4	select name from user where id=1;(N1)
5		rollback;
6	select name from user where id=1;(N2)
7	commit;

在读未提交的隔离级别下，N1的值是「重塑」，因为事务B的回滚，N2的值是「刺猬」。这里在N1处就产生了脏读，显然N1处的查询效果是一个脏数据，会对正常业务发生影响。

脏读会产生在读未提交的隔离级别中。

4.2 不成反复读（Non-Repeatable Read）

不成反复读（Non-Repeatable Read）是指，两次施行雷同的查询可能会得到不同的效果。

继续运用介绍隔离级别时的AB事务案例，同时假如隔离级别为读已提交：

时刻	事务A	事务B
1	begin;
2		begin;
3		update user set name='重塑' where id=1;
4	select name from user where id=1;(N1)
5		commit;
6	select name from user where id=1;(N2)
7	commit;
8	select name from user where id=1;(N3)

在读已提交的隔离级别下，事务可以读取到其他事务提交的数据。在上述案例中效果是N1=刺猬，N2=重塑，N3=重塑，在事务A中，有两次雷同的查询N1和N2，但是这两次查询的效果并不雷同，这就产生了不成反复读。

不成反复读会产生在读未提交、读已提交的隔离级别中。

4.3 幻读（Phantom Read）

幻读（Phantom Read）是指，一个事务在读取某个范畴内记载时，别的一个事务在该范畴内插入一条新记载，当以前的事务再次读取这个范畴的记载时，会读到这条新记载。

看下面的案例，假如此时隔离级别为可反复读：

时刻	事务A	事务B
1	begin;
2	select name from user;(N1)
3		begin;
4		insert into user values(2, '五条人');
5		commit;
6	select name from user;(N2)
7	select name from user for update;(N3)
8	commit;

事务A有三次查询，在N1和N2之间，事务B施行了一条 insert语句并提交，N3处的查询运用的是 for update。

N1处的效果很显然只要「刺猬」，N2处的效果因为事务A开启在事务B以前，所以也是「刺猬」，而N3处的效果理论上在可反复读的隔离级别中也应当只要「刺猬」，但现实上N2的效果是「刺猬」和「五条人」，这就产生了幻读。

这就很蹊跷怪僻了，不是说可反复读的隔离级别能够保障一个事务中屡次查询雷同的记载，效果总是一致的吗？这种效果并谴责脚可反复读的定义。

事实上，在可反复读的隔离级别下，要是运用的是目前读，那么就可能产生幻读现象。

目前读和快照读会鄙人文中介绍事务的实现道理及 MVCC 时计议，这里先给一个结论。

幻读会产生在读未提交、读已提交、可反复读的隔离级别中。

这里需要额外注意的是：幻读和不成反复读都是说在一个事务中的统一个查询语句效果不一样，但幻读更偏重于查询到其他事务新插入的数据（insert）或其他事务删除的数据（delete），而不成反复读的范畴更广，只有效果不一样就可以以为是不成反复读，但个别我们以为不成反复读更偏重于其他事务对数据的更新（update）。

4.4 小结

通过上面的描述，我们已经晓得四种隔离级另外概念以及它们离别会碰到的题目，事务的隔离级别越高，隔离性就越强，所碰到的题目也就越少。但同时，隔离级别越高，并发能力就越弱。

下表是对隔离级另外概念不一样隔离级别会产生的题目状况的小结：

隔离级别	脏读	不成反复读	幻读	概念
读已提交	√	√	√	事务中的修改，即使没有提交，对其他事务也都是可见的
读未提交		√	√	事务中的修改只要在提交之后，才会对其他事务可见
可反复读			√	一个事务中屡次查询雷同的记载，效果总是一致的
可串行化				事务都是串行施行的，读会加读锁，写会加写锁

5. MVCC

MVCC（Multi-Version Concurrency Control）即多版本并发控制，这是 MySQL 为了提高数据库并发机能而实现的。它可以在并发读写数据库时，保障不一样事务的读-写操纵并发施行，同时也能解决脏读、不成反复读、幻读等事务隔离题目。

在前文计议幻读的时候提到过目前读的概念，正是因为目前读，才会在可反复读的隔离级别下也会产生幻读的状况。

在解释可反复读隔离级别下产生幻读的缘由以前，第一介绍 MVCC 的实现道理。

5.1 MVCC 的实现道理

第一我们需要晓得，InnoDB 的数据页中每一行的数据是有隐蔽字段的：

• DB_ROW_ID: 隐式主键，若表构造中不决义主键，InnoDB 会主动生成该字段作为表的主键
• DB_TRX_ID: 事务ID，代表修改此行记载的最后一次事务ID
• DB_ROLL_PTR: 回滚指针，指向此行记载的上一个版本（上一个事务ID对应的记载）

每一条修改语句都会响应地记载一条回滚语句（undo log），要是把每一条回滚语句视为一条数据表中的记载，那么通过事务ID和回滚指针就可以将对统一行的修改记载看作一个链表，链表上的每一个节点就是一个快照版本，这就是 MVCC 中多版本的意思。

举个例子，假如对 user 表中独一的一行「刺猬」进行屡次修改。

update user set name='重塑' where id=1;update user set name='木马' where id=1;update user set name='达达' where id=1; 

那么这笔记录的版本链就是：

N1，N2处的查询想必已经十清楚确都是「刺猬」了。而在N3处所运用的查询语句是for update，运用它进行查询就会对指标记载增加一把「行级锁」，行级锁的意义今后再说，此刻只需要晓得for update能够锁住指标记载就可以了。

加锁天然是防止他人修改，那么天经地义，锁住的固然也就是记载的最新版本了。所以，在运用for update进行查询的时候，会运用目前读，读到指标记载的最新版本，所以在N3处的查询语句就会把事务B中本关于事务A来说不成见的记载也查询出来，也就产生了幻读。

运用目前读的语句有：

• select ... for update
• select ... lock in share mode（同享读锁）
• update ...
• insert ...
• delete ...

6. 数往知来

1. 事务的ACID四大特性
2. 主动提交与隐式提交（隐式提交的语句）
3. 事务的隔离级别
4. 事务各个隔离级别可能涌现的题目
5. MVCC 的实现道理与历程
6. RC 与 RR 生成读视图的机会

更多相干免费学习举荐：mysql教程(视频)

以上就是我所了解的MySQL之四：事务、隔离级别及MVCC的细致内容，更多请关注 百分百源码网 其它相干文章！