MySQL隔离性及Spring事务

一、数据库事务ACID特性

　　必须要掌握事务的4个特性，其中事务的隔离性之于MySQL，对应4级隔离级别。

• 原子性(Atomicity)：

　　　事务中的所有原子操作，要么都能成功完成，要么都不完成，不能停滞在中间环节。发生错误要回滚至事务开始前状态，仿佛事务没有发生过。

• 一致性(Consistency)：

　　　事务必须始终保持数据库系统处于一致的状态，无论并发多少事务。

• 隔离性(Isolation)：

　　　事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要存在相互隔离。[MySQL隔离级别]

• 持久性(Durability)：

  持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。

二、MySQL隔离级别

 select @@tx_isolation ；                         --查询MySQL隔离级别
 set <level> tx_isolaction  = 'READ-COMMITTED'；    --设置事务隔离级别level分为session默认，global全局
 start transaction ；                             -- 启动事务
 set savepoint <point_name>  ；                    --设置回滚点，mysql支持回滚点
 rollback    ；                                   --回滚全部
 rollback to <savepoint_name> ；                  --回滚至某回滚点
 commit ；                                        --提交事务

事务常用SQL命令

MySQL支持的隔离级别

• 读未提交(READ-UNCOMMITTED)

  　　这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。

• 读/写提交(READ-COMMITTED)

  　　保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。

  快照读（Snapshot Read）在事务A尚未提交时，其他事务仍然可以读到表中数据（不含未提交）即为快照读

  与之对应的还有当前读（Current Read），若事务A不提交，当前读便会阻塞waiting... (select * from t1 for update )

  在RC级别下快照读在更新，即若有其他事务提交，则更新数据快照，这也是不可重复读产生的原因。而RR级别下同一事务只有一版数据快照来实现可重复读

• √ 可重复读(REPEATABLE-READ)(MySQL默认此级别)

  　　MySql的默认隔离级别，当第一次读取到数据时就对数据加s锁(共享锁)，就不允许其他事务进行“修改操作（Update 、delete会加x锁，排它锁 s与x互斥）”了，而“不可重复读”恰恰是因为两次读取之间进行了数据的修改。

  多版本并发控制（MVCC,Multiversion Currency Control）见下文

• 序列化(SERIALIZABLE)

  　　这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行，读取数据加s锁，写加x锁，读写互斥。可以有效避免不可重复读取、幻读、脏读问题，但会极大的降低数据库的并发能力。

常见错误

• 脏读：允许一个事务A去读取另外一个事务B未提交的数据。（未提交即未确认，所以A事务读到脏数据的可能性非常高）

• 不可重复读：同一条数据被多个事务影响，造成数据动态变化，不能重复读取。（事务A前后多次查询的同一条数据结果不一致，即该条数据不可重复读。原因是事务B在A多次读取间隙修改过该数据）

• 幻读：在一个事务中，第二次select多出了row就算幻读（MySQL官方定义），不可重复读针对的是数据的修改、删除，而幻读针对破坏数据整体性insert操作。

-- RR级别下：
-- 情景1
--事务A添加一条新数据，
select * from t1 ;
+----+--------------+------------+
| id | class_name   | teacher_id |
+----+--------------+------------+
|  3 | 初二一班     |          2 |
|  4 | 初二二班     |          2 |
|  5 | 初三三班     |          2 |
+----+--------------+------------+
insert into t1 (class_name,teacher_id) values ('初三一班',3);
--1行被影响
select * from t1 ;
+----+--------------+------------+
| id | class_name   | teacher_id |
+----+--------------+------------+
|  3 | 初二一班     |          2 |
|  4 | 初二二班     |          2 |
|  5 | 初三三班     |          2 |
|  6 | 初三一班     |          3 |
+----+--------------+------------+
commit ;
--事务B查询所有 (RR级别不发生不可重复读)
select * from t1 ;
+----+--------------+------------+
| id | class_name   | teacher_id |
+----+--------------+------------+
|  3 | 初二一班     |          2 |
|  4 | 初二二班     |          2 |
|  5 | 初三三班     |          2 |
+----+--------------+------------+
--事务B插入操作
insert into t1 values(6,'初一一班',4);
--插入失败，但select 操作又不会发现id= 6 的数据

RR级别幻读情景1

-- 情景2
-- 事务A 查询表t1
select * from t1 ;     -- 假设为3条数据
-- 事务B查询表t1(加s锁)
select * from t1 ;     -- 假设为3条数据
-- 事务A向t1插入1数据
insert into t1 values(6,'初一一班',4);
select * from t1 ;     -- 4条数据，注意是事务A查询
-- 当事务B修改'全部数据'时会发现
update t1 set teacher_id = 888 ;    -- 4条数据被影响
select * from t1 ;     --3条数据
-- 查询和修改的记录条数不一致，查询是查不到事务A新插入的数据的，但修改却可以成功修改事务A新插入的数，幻读。

RR级别幻读情景2

-- 在RC级别的下幻读操作很容易实现
-- 事务A修改操作
update t1 set class_name = '初三四班' where teacher_id= 2 ； -- 2行数据被影响
--这时事务B插入操作
insert into t1 (class_name,teacher_id) values ('初三三班',2)； -- 1行数据被影响
commit ;
--当事务A查询
select * from t1 where teacher_id = 2 ;
+----+--------------+------------+
| id | class_name   | teacher_id |
+----+--------------+------------+
|  3 | 初二一班     |          2 |
|  4 | 初二二班     |          2 |
|  5 | 初三三班     |          2 |
+----+--------------+------------+
--合计3条数据，出现幻读现象

RC级别幻读

	脏读	不可重复读	幻读
READ-UNCOMMITTED	√	√	√
READ-COMMITTED	×	√	√
REPEATABLE-READ	×	×	√
SERIALIZABLE	×	×	×

MVCC相关的锁

多版本并发控制（MVCC,Multiversion Currency Control）

　　不可重复读和幻读最大的区别，就在于如何通过锁机制来解决他们产生的问题。上文说的，是使用悲观锁机制来处理这两种问题，但是MySQL、ORACLE、PostgreSQL等成熟的数据库，出于性能考虑，都是使用了以乐观锁为理论基础的MVCC来避免这两种问题。

• 悲观锁

  　　正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

  在悲观锁的情况下，为了保证事务的隔离性，就需要一致性锁定读。读取数据时给加锁，其它事务无法修改这些数据。修改删除数据时也要加锁，其它事务无法读取这些数据(序列化级别)

• 乐观锁

  　　相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。

  　　而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本号与数据库表对应记录的当前版本号进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

  要说明的是，MVCC的实现没有固定的规范，每个数据库都会有不同的实现方式，这里讨论的是InnoDB的MVCC。

• NEXT—KEY锁

  　　NEXT—KEY锁是行锁和gap（间隙锁）的合并，行锁可以避免不同事务对相同数据的修改冲突，但无法避免insert操作问题　　

   --在RR级别下
   --事务A修改操作
   update t1 set class_name = '初二三班' where id = 4 ;
   --这时行锁会锁定id = 4的数据行，不允许其他事务进行修改或删除操作
   --同时gap锁会锁定id = 4数据行的相邻区间，屏蔽其他事务在该区间内的插入操作
   --如果使用的是没有索引的字段，比如：
   update t1 set class_name ='初二三班' where teacher_id = 2
   --（即使没有匹配到任何数据）那么也会给全表加入gap锁。
   --同时，它不能像行锁一样经过MySQL Server过滤自动解除不满足条件的锁
   --因为没有索引，则这些字段也就没有排序，也就没有区间。除非该事务提交，否则其它事务无法插入任何数据。
   --行锁防止别的事务修改或删除，GAP锁防止别的事务新增
   --行锁和GAP锁结合形成的的Next-Key锁共同解决了RR级别在[写数据时的]幻读问题。

MVCC在MySQL的InnoDB中的实现

在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。 在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。 在可重读RR事务隔离级别下：

• SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。（快照读）

• INSERT时，保存当前事务版本号为行的创建版本号

• DELETE时，保存当前事务版本号为行的删除版本号

• UPDATE时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除的行　　

  　　通过MVCC，虽然每行记录都需要额外的存储空间，更多的行检查工作以及一些额外的维护工作，但可以减少锁的使用，大多数读操作都不用加锁，读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行，也只锁住必要行。我们不管从数据库方面的教课书中学到，还是从网络上看到，大都是上文中事务的四种隔离级别这一模块列出的意思，RR级别是可重复读的，但无法解决幻读，而只有在Serializable级别才能解决幻读。于是我就加了一个事务C来展示效果。在事务C中添加了一条teacher_id=1的数据commit，RR级别中应该会有幻读现象，事务A在查询teacher_id=1的数据时会读到事务C新加的数据。但是测试后发现，在MySQL中是不存在这种情况的，在事务C提交后，事务A还是不会读到这条数据。可见在MySQL的RR级别中，是解决了部分幻读的读问题的。

三、Spring事务

　　有关Spring事务仅做简单实例说明，相关底层及原理不介绍，可能会觉得虎头蛇尾，日后会单独出一节关于Spring事务的帖子。

传播行为是指方法之间的调用事务策略的问题。

传播行为	含义	备注
REQUIRED	不存在创建新事务，存在沿用之前的事务	Spring默认传播行为
SUPPORTS	不存在不创建，存在沿用之前的事务	-
MANDATORY	方法必须在事务中运行	没有事务，抛出异常
REQUIRES_NEW	无论是否存在事务，都会在新的事务中运行	事务管理器自动创建新的
NOT_SUPPORTED	不支持事务，存在事务会挂起，知道方法结束恢复	适用于不需要事务的SQL
NEVER	不支持事务，不能在事务环境下运行	存在事务，抛出异常
NESTED	嵌套事务，支持内部事务回滚，不影响主事务	savepoint保存点

四、Spring事务实例

 //基于ssm整合之后的项目，完成批量操作示例d
 //1.创建两个service A 、B   A负责单条插入  B负责批量插入 B循环调用A的方法
 //B为默认隔离级别，默认spring事务传播行为   A为默认隔离级别，REQUIRES_NEW的传播行为
 //DAO层略
 @Transactional(isolation=Isolation.DEFAULT,propagation=Propagation.REQUIRED)
     public int insertStudentList(List<Students> list) {
         // TODO Auto-generated method stub
         int count = 0 ;
         for(Students stu : list) {
             try {
                 count += service.insertStudent(stu);
             }catch(DuplicateKeyException e) {
                 System.err.println(e);
                 System.err.println(stu+"该数据出现了异常 。。。。。。。。");
             }
         }
         System.out.println("新增"+count+"条数据...");
         return count ;
 }
 //注意需要异常处理，SpringTX根据是否出现异常判断

<!-- spring-service.xml  配置事务管理器 -->
    <bean id="transactionManager"
        class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <!-- 注入数据库连接池 -->
        <property name="dataSource" ref="dataSource" />
    </bean>
​
    <!-- 配置基于注解的声明式事务 -->
    <tx:annotation-driven transaction-manager="transactionManager" />

spring.xml

五、常见Spring事务的使用错误

• static 方法和非public方法 @Transactional注解失效

• 同一个类中（主要针对service层），A方法调用B方法 @Transactional失效

• 相同controller中调用两次相同事务Service，会产生两个事务

• 切勿时间占用事务

• 错误的异常捕捉