数据库的隔离级别

很多人都晓得数据库的隔离级别有四种,分别是

  • read uncommitted
  • read committed
  • repeatable read
  • serializable

但是我相信,有很大一部分人只是单纯的记住了,或者是通过视频学习了,但是很快又忘记了,我想这很可能就是因为没有完全理解透这个东西吧,接下来,我将用我自己的理解来解释,如果有啥需要改进的，大家可以联系我，一起学习.
话不多说,开整!
要理解数据库的隔离级别,首先要理解一些概念,我将从3w来解释
什么是事务?我想大家应该对此都有一定的了解了,事务就是有一个或者一组操作,他们要么同时发生,要么都不发生,所以他的特点就是原子性、一致性、隔离性和持久性
为什么存在事务?我们仔细想一想,为什么需要存在事务?我用一个老生常谈的栗子来说明,你用支付宝向银行卡转账1万,这个可以当作一个事务嘛。这个事务由两个操作构成,支付宝里面的钱减掉一万,银行卡里面的钱加1万，就在你转账的时候,你支付宝里面的钱被扣掉,但是这时银行突然系统故障了,但是你支付宝里面的钱已经被扣掉了,怎么办,我好慌,白白给损失了一万?那不行!所以事务就出来了,他保证转账过程中的一致性和原子性,你银行卡里没加钱,我支付宝就不能扣钱,如果不一致,我就回滚,把支付宝里的钱加回来.结束转账后,数据持久保留,就是持久性,同时不止你一个人转,多个事务之间,互不影响,这就是隔离性.
怎样去使用事务?事务确实很重要，我们应该怎样去合理使用事务?有人可能会有疑问，事务不是保证了一组操作之间的一致性吗?不就直接使用就行了吗?答案是显然的,在当今社会存在很多并发处理的情况,如果只是简简单单地使用事务串行化，用户体验将大大折扣,这就涉及到控制并发的问题了。以最简单的抢票系统为例嘛.我们每个人到12306上去买票,这一组操作可以当作是一个事务,每个人买票都是一个事务。假设有A,B事务同时购票,A,B读操作,都读到12306还剩一张票;A,B买票,票数减一后都是0，然后写回12306的数据库,很明显破环了事务的隔离性,导致数据库的数据不一致;但确实处理速度非常快,不像如果完全满足事务的ACID特性,B只能等到A处理完之后才能进行查看票和购票操作,用户体验相当差.
说了这么多,总结一下吧,数据库的隔离级别是建立在事务的基础上的,但是级别的高低会直接影响事务的ACID特性是否完全满足。
接下来介绍由于控制并发会产生的三种问题(不同程度上的对事务的ACID的破环)

  • lost update
    丢失修改,A、B读取同一数据并修改,B的提交覆盖掉A的提交,导致事务A的修改失效
  • non-repeatable read
    事务A读取某一个数据对象,事务B更新操作,使A无法再现前一次读取的结果.如果仔细划分的话可以划分出三种.1.修改的数据;2.删除的数据;3.添加的数据.就是所谓的更新操作.后两者又称为幻读(虚读)
  • dirty read
    在我的理解就是读到了其他事务未提交的数据,并在这个基础上做了其他操作,比如说回滚

https://blog.csdn.net/wxyf2018/article/details/100423329
https://blog.csdn.net/weixin_39625809/article/details/80707695