MySQL事务及Spring隔离级别实现原理详解-巨人网络通讯

主页 > 知识库 > MySQL事务及Spring隔离级别实现原理详解

MySQL事务及Spring隔离级别实现原理详解

1、事务具有ACID特性

原子性（atomicity）：一个事务被事务不可分割的最小工作单元，要么全部提交，要么全部失败回滚。
一致性（consistency）：数据库总是从一致性状态到另一个一致性状态，它只包含成功事务提交的结果
隔离型（isolation）：事务所做的修改在最终提交一起，对其他事务是不可见的
持久性（durability）：一旦事务提交，则其所做的修改就会永久保存到数据库中。

2、事务的隔离级别

1）隔离级别的定义与问题

READ UNCOMMITTED（读未提交）：事务的修改，即使没有提交，对其他事务也都是可见的。事务能够读取未提交的数据，这种情况称为脏读。
READ COMMITTED（读已提交）：事务读取已提交的数据，大多数数据库的默认隔离级别。当一个事务在执行过程中，数据被另外一个事务修改，造成本次事务前后读取的信息不一样，这种情况称为不可重复读。
PEPEATABLE READ（可重复读）：这个级别是MySQL的默认隔离级别，它解决了脏读的问题，同时也保证了同一个事务多次读取同样的记录是一致的，但这个级别还是会出现幻读的情况。幻读是指当一个事务A读取某一个范围的数据时，另一个事务B在这个范围插入行，A事务再次读取这个范围的数据时，会产生幻行。特别说明：InnoDB和XtraDB存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）解决了幻读问题，它使用间隙锁（next-key locking）锁定查询涉及的行和索引中的间隙，防止幻影行的插入。
SERIALIZABLE（可串行化）：这个事务是最高的隔离级别，它强制事务串行执行，避免了幻读问题。简单来说，SERIALIZABLE会在读取的每一行数据上都加锁，所以可能会导致大量的超时和锁竞争

隔离级别	脏读可能性	不可重复度可能性	幻读可能性	加锁读
READ UNCONMITED	Yes	Yes	Yes	No
RED COMMITED	No	Yes	Yes	No
REPEATABLE READ	No	No	Yes	No
SERIALIZABLE	No	No	No	Yes

2）如果查看修改和MySQL的隔离级别

show variables like 'tx_isolation';  # 查看隔离级别，MySQL8以前
show variables like 'transaction_isolation'; # 查看隔离级别，MySQL8

set global transaction_isolation='READ-COMMITTED'; // 设置隔离级别，阀域READ-UNCOMMITTED、READ-COMMITTED、REPEATABLE-READ、SERIALIZABLE

事务的隔离级别可以是Session层的，我们可以对不同的Session设置不同级别：

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;

3）Spring事务隔离级别

Spring事务默认使用数据库的隔离级别，可以通过注解@Transactional中的isolation参数调整Session级的隔离级别。隔离级别是会话级别的，JDBC的java.sql.Connection接口支持隔离级别的设置。

Spring在开启事务时（DataSourceTransactionManager.doBegin），根据注解配置，对Connection的隔离级别进行设置：

MySQL驱动com.mysql.cj.jdbc.ConnectionImpl执行SQL语句调整会话级的隔离级别

3、死锁

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环。死锁示例：

# 事务一
start transaction;
update account set money=10 where id=1;
update account set money=20 where id=2;
commit;

# 事务二
start transaction;
update account set money=10 where id=2;
update account set money=20 where id=1;
commit;

假设碰巧，事务一和事务二同时执行完第一个update语句，接着准备执行第二条update语句，却发现记录已被对方锁定，然后2个事务都等待对方释放资源，同时持有对方需要的锁，这样就会出现死循环。

为了避免死锁问题，数据库实现了各种死锁检测和死锁超长机制，InnoDB处理死锁的方式是：将持有最少行级排他锁的事务进行回滚。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。

您可能感兴趣的文章: