spring mvc 怎么样设置mysql事物隔离级别

先来总体说一下我对这个问题的理解，用一句话概括：

我们提供的服务有：成都做网站、成都网站设计、微信公众号开发、网站优化、网站认证、肥东ssl等。为近1000家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的肥东网站制作公司

数据库是可以控制事务的传播和隔离级别的，Spring在之上又进一步进行了封装，可以在不同的项目、不同的操作中再次对事务的传播行为和隔离级别进行策略控制。

注意：Spring不仅可以控制事务传播行为（PROPAGATION_REQUIRED等），还可以控制事务隔离级别（ISOLATION_READ_UNCOMMITTED等）。

（以下是个人理解，如果有瑕疵请及时指正）

下面我具体解释一下：

为了大家能够更好的理解，先来明确几个知识点：

事务的传播行为：简单来说就是事务是手动提交还是自动提交，事务什么时候开始，什么时候提交。

事务的隔离级别：简单来说，就四个，提交读，提交读，重复读，序列化读。

首先我来描述一下，数据库（mysql）层面上对于事务传播行为和隔离级别的配置和实验方法：

数据库层面（采用命令行）：其实mySql命令行很简单，希望实验操作一下：

//连接数据库，我这里是本地，后面是用户名密码，不要打分号，如果指令不行，配置下环境变量，网上有很多。

1. cmd中执行：mysql -hlocalhost -uroot -pmysql

//查看本地数据库事务传播行为是手动提交（0），还是自动提交（1）。

2.select @@autocommit;

//如果是0，希望设置为手动提交,这里其实是设置本对话的autocommit，因为如果你再开一个cmd，发现还是没改回来，如果想修改全局的，网上有global方法。

3.set @@autocommit=0;

//然后查询本地数据库中的一条记录,我本地数据库为test1;

4.use test1;

5.select * from task where taskid=1;

//同时新开一个窗口cmd，连接数据库，并且修改这条记录，update语句我就不写了，或者直接修改数据库本条记录。

//再次执行select * from task where taskid=1;发现值没变。OK因为此时数据库隔离级别为repeatable read 重复读，因为mysql默认的隔离级别是重复读。

//修改数据库隔离级别

6.set global transaction isolation level read committed;

//查看一下，可能需要重新连接一下

7.select @@tx_isolation;

//这时在执行一下4,5操作，发现值变了，ok。因为已经改变了数据库隔离级别，发生了重复读出不同数据的现象。

（以上操作希望有不明白的上网自学一下，很有用，先把数据库隔离级别弄明白了）

然后再来讲一下，Spring对事务传播行为和隔离级别的二次封装。

因为不同项目可能在一个mysql的不同数据库上，所以可以在项目中配置数据库的传播行为和隔离级别：

关于spring的传播行为（PROPAGATION_REQUIRED、PROPAGATION_REQUIRED等），我《数据库隔离级别（mysql+Spring）与性能分析 》文章中有讲，网上也有很多相关资料，我就不说了。

关于spring的事务隔离级别与数据库的一样，也是那四个，多了一个default，我也不仔细讲了。

下面主要讲一下spring的配置方法：

property name="transactionAttributes"

props

prop key="save*"PROPAGATION_REQUIRED/prop

prop key="update*"PROPAGATION_REQUIRED/prop

prop key="delete*"PROPAGATION_REQUIRED/prop

prop key="get*"PROPAGATION_REQUIRED,readOnly/prop

prop key="find*"PROPAGATION_REQUIRED,ISOLATION_READ_UNCOMMITTED/prop

/props

就以find为例，可以配置这么配置，前面是控制传播行为，后面是控制事务隔离级别的。那么这时哪怕数据库层面上是重复读，但是还是以这里为准，你会发现在同一个事务中两次查询的结果是不一样的。

最后扫除一个盲区，readonly这个属性，是放在传播行为中的，一般书都这么归类，我也尝试了一下，readonly并不能影响数据库隔离级别，只是配置之后，不允许在事务中对数据库进行修改操作，仅此而已。

mysql 隔离级别设置为什么比较好

术式之后皆为逻辑，一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。

隔离级别的产生

在串型执行的条件下，数据修改的顺序是固定的、可预期的结果，但是并发执行的情况下，数据的修改是不可预期的，也不固定，为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果，由此产生了隔离级别。

所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。

事务的4种隔离级别

READ UNCOMMITTED       未提交读，可以读取未提交的数据。READ COMMITTED         已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句，                       InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。                       Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ        可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE           序列化

在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身间隙)，以及了解整个数据范围的全集组成。

数据范围全集组成

SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；

SQL 语句根据条件扫描到的可能需要加锁的数据范围；

以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）

1. 数据已经填充了整个数据范围：（被完全填充的数据范围，不存在数据间隙）

整形，对值具有唯一约束条件的数据范围 1～5 ，

已有数据1、2、3、4、5，此时数据范围已被完全填充；

整形，对值具有唯一约束条件的数据范围 1 和 5 ，

已有数据1、5，此时数据范围已被完全填充；

2. 数据填充了部分数据范围：（未被完全填充的数据范围，是存在数据间隙）

整形的数据范围 1～5 ，

已有数据 1、2、3、4、5，但是因为没有唯一约束，

所以数据范围可以继续被 1～5 的数据重复填充；

整形，具有唯一约束条件的数据范围 1～5 ，

已有数据 2，5，此时数据范围未被完全填充，还可以填充 1、3、4 ；

3. 数据范围内没有任何数据（存在间隙）

如下：

整形的数据范围 1～5 ，数据范围内当前没有任何数据。

在了解了数据全集的组成后，我们再来看看事务并发时，会带来的问题。

无控制的并发所带来的问题

并发事务如果不加以控制的话会带来一些问题，主要包括以下几种情况。

1. 范围内已有数据更改导致的：

更新丢失：当多个事务选择了同一行，然后基于最初选定的值更新该行时，

由于每个事物不知道其他事务的存在，最后的更新就会覆盖其他事务所做的更新；

脏读： 一个事务正在对一条记录做修改，这个事务完成并提交前，这条记录就处于不一致状态。

这时，另外一个事务也来读取同一条记录，如果不加控制，

第二个事务读取了这些“脏”数据，并据此做了进一步的处理，就会产生提交的数据依赖关系。

这种现象就叫“脏读”。

2. 范围内数据量发生了变化导致：

不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，

却发现其读出的数据已经发生了改变，或者某些记录已经被删除了。

这种现象就叫“不可重复读”。

幻读：一个事务按相同的查询条件重新读取以前检索过的数据，

却发现其他事务插入了满足其查询条件的新数据，这种现象称为“幻读”。

可以简单的认为满足条件的数据量变化了。

因为无控制的并发会带来一系列的问题，这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发，以实现我们所期望的结果(隔离级别)。

MySQL 隔离级别的实现

InnoDB 通过加锁的策略来支持这些隔离级别。

行锁包含：

Record Locks

索引记录锁，索引记录锁始终锁定索引记录，即使表中未定义索引，

这种情况下，InnoDB 创建一个隐藏的聚簇索引，并使用该索引进行记录锁定。

Gap Locks

间隙锁是索引记录之间的间隙上的锁，或者对第一条记录之前或者最后一条记录之后的锁。

间隙锁是性能和并发之间权衡的一部分。

对于无间隙的数据范围不需要间隙锁，因为没有间隙。

Next-Key Locks

索引记录上的记录锁和索引记录之前的 gap lock 的组合。

假设索引包含 10、11、13 和 20。

可能的next-key locks包括以下间隔，其中圆括号表示不包含间隔端点，方括号表示包含端点：

(负无穷大, 10]    (10, 11]    (11, 13]    (13, 20]    (20, 正无穷大)        对于最后一个间隔，next-key将会锁定索引中最大值的上方，

左右滑动进行查看

"上确界"伪记录的值高于索引中任何实际值。

上确界不是一个真正的索引记录，因此，实际上，这个 next-key 只锁定最大索引值之后的间隙。

基于此，当获取的数据范围中，数据已填充了所有的数据范围，那么此时是不存在间隙的，也就不需要 gap lock。

对于数据范围内存在间隙的，需要根据隔离级别确认是否对间隙加锁。

默认的 REPEATABLE READ 隔离级别，为了保证可重复读，除了对数据本身加锁以外，还需要对数据间隙加锁。

READ COMMITTED 已提交读，不匹配行的记录锁在 MySQL 评估了 where 条件后释放。

对于 update 语句，InnoDB 执行 "semi-consistent" 读取，这样它会将最新提交的版本返回到 MySQL，

以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配。

总结延展：

唯一索引存在唯一约束，所以变更后的数据若违反了唯一约束的原则，则会失败。

当 where 条件使用二级索引筛选数据时，会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时，都会等待锁。

行锁的增加是一行一行增加的，所以可能导致并发情况下死锁的发生。

例如，

在 session A 对符合条件的某聚簇索引加锁时，可能 session B 已持有该聚簇索引的 Record Locks，而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。

session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引。

session A 通过索引 idA，session B通过索引 idB 。

当 where 条件获取的数据无间隙时，无论隔离级别为 rc 或 rr，都不会存在间隙锁。

比如通过唯一索引获取到了已完全填充的数据范围，此时不需要间隙锁。

间隙锁的目的在于阻止数据插入间隙，所以无论是通过 insert 或 update 变更导致的间隙内数据的存在，都会被阻止。

rc 隔离级别模式下，查询和索引扫描将禁用 gap locking，此时 gap locking 仅用于外键约束检查和重复键检查（主要是唯一性检查）。

rr 模式下，为了防止幻读，会加上 Gap Locks。

事务中，SQL 开始则加锁，事务结束才释放锁。

就锁类型而言，应该有优化锁，锁升级等，例如rr模式未使用索引查询的情况下，是否可以直接升级为表锁。

就锁的应用场景而言，在回放场景中，如果确定事务可并发，则可以考虑不加锁，加快回放速度。

锁只是并发控制的一种粒度，只是一个很小的部分：

从不同场景下是否需要控制并发，(已知无交集且有序的数据的变更，MySQL 的 MTS 相同前置事务的多事务并发回放)

并发控制的粒度，(锁是一种逻辑粒度，可能还存在物理层和其他逻辑粒度或方式)

相同粒度下的优化，(锁本身存在优化，如IX、IS类型的优化锁)

粒度加载的安全性能(如获取行锁前，先获取页锁，页锁在执行获取行锁操作后即释放，无论是否获取成功)等多个层次去思考并发这玩意。

MySQL 是如何实现四大隔离级别的

SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。

Read Uncommitted（读取未提交内容）

在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。

Read Committed（读取提交内容）

这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。

Repeatable Read（可重读）

这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

Serializable（可串行化）

这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如：

脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。

不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。

幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

在MySQL中，实现了这四种隔离级别，分别有可能产生问题如下所示：

mysql默认事务隔离级别

SQL标准中支持4种事务隔离级别，READ_UNCOMMITTED（读未提交），READ_COMMITTED（读已提交），REPEATABLE_READ（可重复读），SERIALIZABLE（串行读），MySQL innodb引擎支持全部这4种事务隔离级别。

工具／原料：

联想Y7000P

Windows10

MySQL6.0

1、启动命令行窗口，连接MySQL数据库

图示，通过MySQL提供的客户端命令mysql连接MySQL数据库。

2、通过系统变量查询数据库当前事务隔离级别

图示，通过查询数据库提供的系统变量 tx_isolation 或 transaction_isolation 的值即可获取当前的事务隔离级别。MySQL数据库默认的事务隔离级别是REPEATABLE_READ (可重复读）。

3、设置本次会话的事务隔离级别

图示，通过命令set session transaction isolation level可以设置本次会话的事务隔离级别，该设置不会影响其他会话，并且设置会随着当前会话的结束而结束。

4、设置全局会话的事务隔离级别

图示，通过命令set global transaction isolation level可以设置全局会话的事务隔离级别，该设置不会影响当前已经连接的会话，设置完毕后，新打开的会话，将使用新设置的事务隔离级别。

5、设置一次操作的事务隔离级别

图示，通过命令set transaction isolation level可设置下一次事务操作的隔离级别，该设置会随着下一次事务的提交而失效。

分享标题：mysql隔离怎么设置好,mysql四种隔离
URL地址：http://kswjz.com/article/hcophe.html