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的隔离级别
?1 2 3 4 | 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设置不同级别:
?1 2 3 4 | 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、死锁
死锁是指两个或多个事务在同一资源上相互占用,并请求锁定对方占用的资源,从而导致恶性循环。死锁示例:
?1 2 3 4 5 6 7 8 9 10 11 | # 事务一 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处理死锁的方式是:将持有最少行级排他锁的事务进行回滚。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持服务器之家。
原文链接:https://www.cnblogs.com/zhi-leaf/p/12807249.html
1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。