MySQL 事务隔离级别 | 张治峰的博客

概述

我们的数据库一般都会并发执行多个事务，多个事务可能会并发的对相同的一批数据进行增删改查操作，可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。这些问题的本质都是数据库的多事务并发问题，为了解决多事务并发问题，数据库设计了锁机制、MVCC多版本并发控制隔离机制,解决多事务并发问题。接下来，我们会依次深入讲解这些机制，让大家彻底理解数据库内部的执行原理。

ACID

事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性。

原子性(Atomicity) : 事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。
一致性(Consistent) : 在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性。
隔离性(Isolation) : 数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。
持久性(Durable) : 事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。

并发事务处理带来的问题

更新丢失(Lost Update)或脏写

当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题–最后的更新覆盖了由其他事务所做的更新。
脏读(Dirty Reads)

一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致的状态;这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此作进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。一句话:事务A读取到了事务B已经修改但尚未提交的数据，还在这个数据基础上做了操作。此时，如果B 事务回滚，A读取的数据无效，不符合一致性要求。
不可重读(Non-Repeatable Reads)

一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了!这种现象就叫做“不可重复读”。一句话:事务A内部的相同查询语句在不同时刻读出的结果不一致，不符合隔离性
幻读(Phantom Reads)

一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。
一句话:事务A读取到了事务B提交的新增数据，不符合隔离性

事务隔离级别

“脏读”、”不可重复读”和”幻读”,其实都是数据库读一致性问题,必须由数据库提供一定的事务隔离机制来解决。

隔离级别	脏读	不可重复读	幻读
读未提交(Read uncommitted)	√	√	√
读已提交（Read committed)	×	√	√
可重复读(Repeatable read)	×	×	√
可串行话(Serializable)	×	×	×

隔离级别设置

常看当前数据库的事务隔离级别

show variables like 'tx_isolation';

设置事务隔离级别

set tx_isolation='REPEATABLE-READ';

数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度上“串行化”进行,这显然与“并发”是矛盾的。同时,不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读”和“幻读”并不敏感,可能更关心数据并发访问的能力。

Mysql默认的事务隔离级别是可重复读，用Spring开发程序时，如果不设置隔离级别默认用Mysql设置的隔离级别，如果Spring设置了就用已经设置的隔离级别

案例分析

先将下面的示例表导出,然后打开两个mysql会话窗口

CREATE TABLE`account`(
`id` int(11) NOT NULL AUTO_INCREMENT, 
`name` varchar(255) DEFAULT NULL, 
`balance` int(11) DEFAULT NULL,
 PRIMARY KEY (`id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO`test`.`account`(`name`,`balance`)VALUES('zhangsan','520'); 
INSERT INTO`test`.`account`(`name`,`balance`)VALUES('lisi','13000');
INSERT INTO`test`.`account`(`name`,`balance`)VALUES('wangwu','1400');

navicat 打开两个会话窗口

读未提交

(客户端A查询数据) 将客户端A当前事务模式设置为read uncommitted(未提交读)，并查询表account的初始值。
set tx_isolation='read-uncommitted';
select * from account;
(客户端B更新数据)打开另一个客户端B，开启事务并更新表account id 为 1 的数据 (不提交事务)。
begin ;
UPDATE account set balance = balance-10 where id =1
(客户端A查询) 这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据 510。
select * from account;
(客户端B错误回滚) 一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据。
ROLLBACK;
(客户端A查询)

再次查询数据 id = 1 的余额还是 520 ，如果应用程序使用开始查到的 510 进行运算操作然后更新就会造成数据不一致，要想解决这个问题可以采用读已提交的隔离级别。

读已提交

(客户端A查询数据) 将客户端A当前事务模式设置为read committed(已提交读)，并查询表account的初始值。
set tx_isolation='read-committed';
select * from account;
(客户端B更新数据)打开另一个客户端B，开启事务并更新表account id 为 1 的数据 (不提交事务)。
begin ;
UPDATE account set balance = balance-10 where id =1
(客户端A查询) 这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数据，解决了脏读问题。
select * from account;
客户端B正常提交事务
COMMIT;
(客户端A再次查询) 客户端A执行与上一步相同的查询，结果与上一步不一致，即产生了不可重复读的问题。
select * from account;

可重复读

(客户端A查询数据) 将客户端A当前事务模式设置为repeatable_read(可重复读)，并查询表account的初始值。
set tx_isolation='repeatable-read';
BEGIN;
select * from account;
(客户端B更新数据)打开另一个客户端B,更新表account并提交
begin ;
UPDATE account set balance = 520 where id =1;
COMMIT;
(客户端A查询) 这时，在客户端A查询表account的所有记录，与步骤(1)查询结果一致，没有出现不可重复读的问题。
select * from account;
客户端B正常提交事务
COMMIT;
(客户端A再次查询) 客户端A执行与上一步相同的查询，结果与上一步不一致，即产生了不可重复读的问题。
select * from account;

串行化

打开一个客户端A，并设置当前事务模式为serializable，查询表account的初始值.
set tx_isolation='serializable';
select * from account where id = 1;
打开一个客户端B，并设置当前事务模式为serializable，更新id为1的记录会被阻塞等待，更新id 为2的记录可以成功，说明在串行模式下innodb的查询也会被加上行锁。
UPDATE account set balance = 520 where id =1;
UPDATE account set balance = 520 where id =2;
这种隔离级别并发性极低，开发中很少会用到。

Tags: mysql

← JOIN 优化及 NLJ&BNL 算法 MySQL 锁机制 →

赏

使用支付宝打赏

使用微信打赏

若你觉得我的文章对你有帮助，欢迎点击上方按钮对我打赏

扫描二维码，分享此文章