mysql spring隔离级别_浅谈MySQL的事务隔离级别

希望这篇文章能够阐述清楚跟数据库相关的四个概念：事务、数据库读现象、隔离级别、锁机制

一、事务

先来看下百度百科对数据库事务的定义：

作为单个逻辑单元执行一系列操作，要么完全执行，要么完全不执行。事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。

事务有四个属性，称为ACID属性：

1、原子性(Atomicity):事务是一个原子单位，要么全部执行，要么全部不执行。

2、一致性(Consistent):事务的开始和结束，数据都必须保持一致状态。

3、隔离性(isolation):数据库系统提供隔离机制，保证并发事务之间是互相不干扰的。也就意味着事务处理过程中的中间状态对其他的事务是透明的。

4、持久性(Durable):事务完成之后，对数据的修改是永久性的，即使出现系统故障也能够保持。

事务是一系列SQL语句的集合，如果没有事务，会出现什么问题？或者说SQL只能一条一条的单个执行，会出现什么问题？

这个很简单，如果没有事务，我们平时生活中的银行转账就无法操作。

二、数据库读现象

ACID属性里面有一个是隔离级别，即并发事务之间互相不干扰。互相不干扰只是一个终极状态，且需要消耗巨大的性能。在我们实际应用过程中，是存在很大的灰度空间的：隔离级别有程度的区分。所以如果隔离程度控制的比较弱的话，就会产生脏读、不可重复读以及幻读的现象。

1、脏读

事务T1修改某个字段的值，然后事务T2读取该值，此后T1撤销了对该字段的更新，或者更新成另外的值才commit到数据库中，这样T2读取的数据是无效的或者错误的。导致T2依据脏数据所做的操作也是错误的。

思聪同学中午去食堂吃饭，看到窗边的座位被如花同学占有了，思聪认为这个座位已经被占有了，就转身去找其他的座位。不料，如花同学起身离开了。事实是：如花并不是吃饭，而是临时坐在那里等她的约会对象，只是临时小坐一会，并没有真正“commit”。

2、不可重复读

在数据库访问中，一个事务范围内的两次相同的查询却返回了不同的数据。

事务T1读取某一数据，事务T2读取并修改了该数据，T1为了对读取值进行验证而重新读取，却发现得到了不同的结果。

思聪同学中午去食堂吃饭，看到窗边的座位是空的，便屁颠屁颠的跑去打饭，回来后却发现这个座位被如花同学抢去了。

3、幻读

幻读解决了不可重复读的问题，即在同一个事务范围内，两次相同的查询结果是相同的。但是可以新增表中的数据记录。

幻读是指事务T1对表中的数据进行修改，假设修改涉及了表中全部的数据行，同时第二个事务也修改这个表中的数据，这种修改是向表中插入一条新的数据。后面就会出现操作了T1事务的用户发现表中还有没有修改的数据行，仿佛出现了幻觉一样。

思聪同学中午去食堂吃饭，看到窗边的座位是空的，便屁颠屁颠的跑去打饭，回来后窗边的座位还是空的，便很高兴坐上去准备开始吃饭，这时候却发现如花同学搬了一个小板凳坐在旁边狼吞虎咽，思聪顿时没有了胃口。

如果需要解决脏读、不可重复读、幻读等这些数据库读现象，就必须相应提高事务的隔离级别。但是数据库的隔离级别越高，对应的并发能力就越弱，性能也就相应的越差，所以我们还需根据具体的应用场景去权衡。

三、事务隔离级别

1、未提交读

事务的最低隔离级别，在这种隔离级别下，一个事务可以读取另外一个事务未提交的数据。

数据库锁实现原理：

事务T在读数据的时候并未对数据进行加锁，事务T在修改数据的时候对数据增加行级共享锁

T1在读取数据时，T2可以对相同数据进行读取、修改。因为T1没有进行任何锁操作；当T2对记录进行修改时，T1再次读取数据可以读取到T2修改后的数据。因为T2对数据进行修改只增加了行级共享锁，T1可以再增加共享读锁进行数据读取(尽管T2没有提交事务)

如上所述，这种隔离级别，会导致脏读现象

2、已提交读

在一个事务修改数据过程中，如果事务没有进行提交，其他事务不能读取该数据

数据库锁实现原理：

事务T在读取数据时增加行级共享锁，读取一旦结束，立即释放；事务T在修改数据时增加行级排他锁，直到事务结束才释放。

T1在读取数据的过程中，T2也可以对相同数据进行读取，但是不能进行修改(T1增加的是共享锁，T2也可以增加共享锁，但是不能增加排他锁)。T1读取结束后，会立即释放共享锁，这时T2可以增加排他锁，对数据进行修改，而此时T1既不能对数据进行读取也不能进行修改，直到T2事务结束。

如上所述，这种隔离级别，解决了脏读问题，但是不能解决不可重复读现象。

3、可重复读

事务T在数据读取时，必须增加行级共享锁，直到事务结束；事务T在修改数据过程中，必须增加行级排他锁，直到数据结束。

数据库锁实现原理：

T1在读取数据的过程中，T2也可以对相同数据进行读取，但是不能进行修改(T1增加的是共享锁，T2也可以增加共享锁，但是不能增加排他锁)。直到T1事务结束后，才会释放共享锁，这时T2才可以增加排他锁，对数据进行修改。

如上所述，这种隔离级别，解决了不可重复读现象，但是这种隔离级别解决不了幻读的问题：

T1进行查询，读取了10条记录，并对十条记录增加了行级锁，此时T2是无法对这10行数据进行修改操作的，但是由于没有表级锁，它可以增加一条满足T1查询条件的记录。随后T1在进行查询时，会发现虽然10条记录没有改变，但是突然多了一条记录。

4、序列化

产生幻读是由于没有进行范围查询时没有增加范围锁。

数据库锁实现原理：

事务T在读取数据时，必须先增加表级共享锁，直到事务结束才释放；事务T在修改数据时，必须先增加表级排他锁，直到事务结束才释放。

T1在读取A表时，增加了表级共享锁，此时T2也可以读取A表，但是不能进行任何数据的修改，直到T1事务结束。随后T2可以增加对A表的表级排他锁，此时T1不能读取A表中的任何数据，更不能进行修改。

如上所述，可序列化解决了脏读、不可重复读、幻读等读现象，但是隔离级别越来越高的同时，在并发性上也就越来越低。

四、事务操作实践

默认情况下，MYSQL是自动提交的，也就意味着平时我们执行一条update语句时，MYSQL是自动帮我们提交的，尽快我们没有显示执行commit命令。但是这种只适用于单条SQL的执行。

如果我们想要同时执行多条SQL，并且执行过程中有SQL执行异常，需要回滚前面已经成功执行的SQL或者最终想回滚全部，则必须显示的使用事务。

开始一项事务：start tr ansaction或者begin；

提交事务：commit；

回滚事务：rollback；

事务提交之后的操作：chain；

事务回滚之后的操作：release；

修改当前连接的提交方式：set autocommit；如果设置了set autocommit=0，则设置之后所有的事务都需要显式的通过命令来进行提交或者回滚。

查询当前会话的事务隔离级别

查询当前系统的事务隔离级别

修改当前会话的事务隔离级别

提交读演示

客户端A 开启事务，并更新数据

此时事务还没有提交，开启客户端B，并进行查询，此时的数据还是未更新前的

客户端A进行事务提交，然后客户端B查询，此时是最新的数据

commit and chain的演示

如果在提交的时候使用commit and chain，那么在提交后立即开始一个新的事务

A提交事务后，B再进行查询

开启事务会隐式解锁

锁表期间，用start transaction 命令开始一个新事务，则会隐式的执行unlock tables

A对表进行写锁操作

此时B进行查询：由于被A锁表，所以查询被阻塞

A开启一个事务

由于A开启事务，隐式的释放了写锁，所以B的查询不再被阻塞

SAVEPOINT的使用

事务中可以通过定义SAVEPOINT，指定回滚事务的一个部分

A开启事务并insert一条记录，并设置savepoint

B进行查询，查询到的是开启事务前的数据

A又插入一条数据，然后回滚到savepoint

B进行查询

作者：冬瓜蔡

原文：http://www.cnblogs.com/dongguacai/p/7114885.html

始发于微信公众号： Java知音