事务特性、隔离级别、@Transactional_transactional isolation-优快云博客

本文链接：https://blog.youkuaiyun.com/ding_xiong/article/details/133375659

本文详细介绍了事务的四个特性——原子性、一致性、隔离性和持久性，并探讨了数据库的四种隔离级别及其示例。此外，文章还深入讲解了Spring框架中的@Transactional注解，包括isolation属性、propagation属性、只读属性、超时属性及异常处理，以及@Transactional注解在某些情况下的失效原因。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

读未提交（READ UNCOMMITTED）

读已提交（READ COMMITTED）

可重复读（REPEATABLE READ）

Propagation.REQUIRES_NEW

只读属性

超时属性

异常属性

@Transactional注解失效情况（重要）

一、事务特性

原子性

事务是一个不可分割的最小工作单元，事务中的所有操作要么全部提交成功，要么
全部失败回滚。

案例:A给B转账，A减少余额和B新增余额这两个操作要么都成功，要么都失败。

一致性

事务总是从一种合理状态转为另一种合理状态，不能出现中间状态。

例如:A银行卡余额减少多少对应B银行卡余额就新增多少，不能说A余额减少了B不变，钱不翼而飞了。

隔离性

事务之间的操作是相互隔离的，各个事务之间互不干扰。

持久性

一旦事务提交，则其所做的修改会永久保存到磁盘（数据库）。

二、事务的隔离级别

数据库默认隔离级别

SQLServer默认隔离级别是读已提交。
MySQL默认隔离级别是可重复读。

隔离级别相关命令

-- 查看默认的隔离级别 两种方式
SHOW VARIABLES LIKE 'transaction_isolation';
SELECT @@transaction_isolation;

-- 开启事务 两种方式
START TRANSACTION或者BEGIN;-- 开启事务
COMMIT; -- 提交
ROLLBACK;-- 回滚

-- 关闭自动提交事务
set autocommit = 0; 

-- 设置会话的隔离级别 
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;-- 读未提交
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 读已提交
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- 可重复读
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;-- 串行化

读未提交（READ UNCOMMITTED）

同时开启两个事务A和B，A事务修改了某条数据还未提交，B事务读取了未提交事务的数据。存在脏读问题。

场景演示:

打开两个Navicate窗口A,B,分别更改MySQL默认隔离级别可重复读 -> 读未提交。

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;-- 读未提交

SHOW VARIABLES LIKE 'transaction_isolation';-- 查看隔离级别

set autocommit = 0; -- 禁止事务自动提交

A窗口开启事务A修改User表中的数据但是不提交。

BEGIN;
UPDATE user SET username="事务A修改" where id = 1;

B窗口开启事务B读取user表id为1的数据。

begin;
select * from user where id = 1

查看表中数据，事务A未提交但是事务B读取到了未提交的数据。脏读。

读已提交（READ COMMITTED）

如何解决脏读问题呢？设置隔离级别为读已提交。

A事务修改了某条数据必须提交事务后B事务才能读取到。存在不可重复读问题。

场景演示:

打开两个Navicate窗口A,B,分别更改MySQL离级别为读已提交。

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;-- 读已提交

SHOW VARIABLES LIKE 'transaction_isolation';-- 查看隔离级别

set autocommit = 0; -- 禁止事务自动提交

A窗口开启事务A修改User表中的数据但是不提交。


BEGIN;
UPDATE user set username="事务A修改" where id= 1;

B窗口开启事务B读取user表id为1的数据

begin;
select * from user where id = 1

查看表中数据对比，事务A未提交，事务B读取原来表中的数据。解决了脏读。

现在A事务提交，B事务读取到数据一定会改变，B事务两次读取数据不一致，称为不可重复读。

可重复读（REPEATABLE READ）

如何解决不可重复读？设置隔离级别为可重复读。

两个事务 A、B，事务 A 对数据进行更新，在当前事务中是能够读到更新，在事务 B 中却读取不到这个更新。存在幻读问题。

场景演示:

打开两个Navicate窗口A,B,分别更改MySQL离级别为可重复读。

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;-- 可重复读

SHOW VARIABLES LIKE 'transaction_isolation';-- 查看隔离级别

set autocommit = 0; -- 禁止事务自动提交

A窗口开启事务A修改User表中的数据但是不提交。


BEGIN;
UPDATE user set username="事务A修改" where id= 1;

B窗口开启事务B读取user表id为1的数据。

begin;
select * from user where id = 1

A窗口提交事务A后，查询表中原始数据

COMMIT;

B窗口事务B查询user表id为1的数据。

可以看到即使A事务提交了，B事务任然读取到的是第一个读取的数据，解决了不可重复读问题。存在幻读问题，当同一个事务多次查询出现不同的结果集，认为是幻读现象,注意幻读体现在最终结果集上以行为单位而不是以行上每列的数据。例如，如果 SELECT 执行了两次，但第二次返回了第一次没有返回的行。在可重复读这个隔离级别MySQL使用MVCC+间隙锁解决了绝大部分幻读。

串行化（SERIALIZABLE）

解决了脏读、不可重复读、幻读问题。

mysql锁:

共享锁:多个事务能够同时对一行数据加共享锁，但是不能加排他锁。数据只读。
排他锁:一个事务在一行数据加上排他锁后，其他事务只能等待锁释放，才能操作该数据。
默认insert、update、delete会对数据行加排他锁。
select语句默认是可以穿锁的，不管数据是共享锁还是排他锁都可以查询。但是select语句一旦加了for update（加排他锁）和lock in share mode（加共享锁）的方式查询数据就失去穿锁的特点。

串行化：读取数据会在数据行和行之间间隙加共享锁，增删改会在数据行和行之间间隙加排他锁。

三、@Transactional

隔离级别isolation属性

@Transactional(isolation = Isolation.DEFAULT)
Isolation枚举类
Isolation.DEFAULT          使用数据库默认值
Isolation.READ_UNCOMMITTED 读未提交
Isolation.READ_COMMITTED   读已提交
Isolation.REPEATABLE_READ  可重复读
Isolation.SERIALIZABLE     串行化
实际开发中通常是使用数据库默认值，不配置@Transactional的isolation属性默认就是Isolation.DEFAULT

传播行为propagation属性

@Transactional(propagation = Propagation.REQUIRED)
Propagation枚举类 最重要的三个枚举值如下:
Propagation.REQUIRED
Propagation.SUPPORTS
Propagation.REQUIRES_NEW

Propagation.REQUIRED

外部方法（调用当前方法的那个方法）不存在事务则新建事务，否则就是共用外部方法的事务。不管内部方法出错还是外部方法出错一起回滚。

Propagation.SUPPORTS

外部方法（调用当前方法的那个方法）不存在事务则当前方法不使用事务，否则就是共用外部方法的事务。不管内部方法出错还是外部方法出错一起回滚。

Propagation.REQUIRES_NEW

外部方法（调用当前方法的那个方法）不存在事务则当前方法新建事务，否则就暂停外部方法的事务，当前方法新建自己的一个事务。

当内部和外部方法都存在事务时:

外部方法出错，内部方法没出错:只会回滚外部方法的事务。

外部方法没出错，内部方法出错:都会回滚

都出错:都会回滚

只读属性

@Transactional(readOnly = false)

readOnly=false/true 默认值时false  表示只读事务不存在数据的修改 

开发中通常只读的场景通常是没有加事务的（没有使用@Transactional）,但是如果只读的场景使用了@Transactional 加上readOnly = true属性可以优化效率

超时属性

@Transactional(timeout = 2) 事务等待超时时间单位s 超时会报异常

默认值-1 却决于数据库设置的事务超时时间

事务等待？可能有事务在执行时候对数据加了锁，其他事务就只能等待这个事务操作完，才能操作。

建议:不用更改

异常属性

@Transactional(
        rollbackFor = {RuntimeException.class,xxx.classs....},
        noRollbackFor = {Exception.class,xxxx.class....}
        )
默认:出现了Error和RuntimeException异常及其子类异常就回滚,Exception及其子类等非运行时异常会提交。

@Transactional注解失效情况（重要）

@Transactional 注解只被应用到 public 修饰的方法上。
同一个类中方法调用，导致@Transactional失效。事务的原理是利用动态代理和AOP，代理对象在目标方法执行前开启事务，执行完提交事务，在同一个类中相互调用是使用的目标对象this，而不是代理对象，导致事务失效。
是否使用了 try catch 进行了异常捕获，并且捕获之后，没有进行异常抛出，方法正常执行完，导致事务不回滚。