为了账号安全,请及时绑定邮箱和手机立即绑定

数据库事务隔离级别简介

标签:
MySQL

Q: 什么是ACID?

A: 四个单词的首字母缩写,其分别为:

  • Atomicity(原子性)

  • Consistency(一致性)

  • Isolation(隔离性)

  • Durability(持久性)

那么缩写的这四个又是什么?来看看WIKI:

In computer science, ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties of database transactions intended to guarantee validity even in the event of errors, power failures, etc.

翻译一下:
在计算机科学中,ACID是数据库事务(Database transactions)的一组属性,用来保证数据库在出错、断电等情况下的正确性(Validity)。
换句话说,数据库中的事务,如果满足了ACID,那么在出错和断电的情况下,也能保证其正确性。所谓正确,也就是在该类场景下,表现的行为符合预期。
那么,什么样的行为才是符合预期的行为?留待后面回答。

K: 事务的属性,正确性
Q: 什么样的行为才是预期的行为?

Q: 什么是事务?

A: 依然来看看wiki:

In the context of databases, a sequence of database operations that satisfies the ACID properties (and these can be perceived as a single logical operation on the data) is called a transaction.

翻译:
在数据库的上下文中,一系列满足ACID条件(并在逻辑上可以认为是对数据的一个操作)的操作,称为事务。
主谓拆分:

  • 事务,是一系列的操作

  • 这一系列的操作,满足ACID

  • 逻辑上,这一系列的操作可以看做是对数据的一个操作

举个例子:
转账:从李四的账户转200块到张三的的账户上。

  • 一系列的操作:

    • 从李四账户上减去200块

    • 在张三账户上加上200块

  • 这一系列的操作符合ACID

  • 逻辑上讲,转账可以看做对数据的一个操作

K: 系列操作,满足ACID,逻辑单个
R: 组合起来,形成事务,all的关系
Q: ACID分别是什么?什么情况才算满足了?

Q: Atomicity是什么?

A: 继续WIKI

An atomic transaction is an indivisible and irreducible series of database operations such that either all occur, or nothing occurs.

翻译:
一个原子事务是指一系列不可分割、不可消减的操作,它们要么全执行,要么全不执行。

首先Atomicity是事务的一个属性,所以解释的时候,必然会涉及到事务。解释具体这个属性的事务的预期行为
这里,有一个我认为十分好记的关键字:All or Nothing,我翻译为所有或无。
K: 事务的属性,All or Nothing

Q: Consistency是什么?

A: WIKI

Consistency in database systems refers to the requirement that any given database transaction must change affected data only in allowed ways.

翻译:
数据库中的一致性,要求数据库事务对数据的影响必须是被允许的。

被谁允许的呢?
数据库本身。数据库具有一些constraints(限制),满足这些限制条件的,即是被允许的,否则就是不被允许的。即不允许,也就是不满足数据库的限制条件。

什么是数据库的限制(Database Constraints)?

A constraint is a property assigned to a column or the set of columns in a table that prevents certain types of inconsistent data values from being placed in the column(s).
-- What is data integrity? Explain constraints

翻译:
一个限制,是应用于数据库表中的一个或者几个列的规则,这些规则防止(与其他列不一样的)不一致的数据被存放到列中。

主谓分析:

  • 限制是规则

  • 针对表中的列的规则

  • 防止不一致的数据出现

数据库的限制(Database Constraints)有哪些?

  • Entity Integrity,保证没有重复的列

  • Domain Integrity ,数据满足定义的格式、类型、范围等

  • Referential integrity ,存在引用的列不能被删除

  • User-Defined Integrity ,用户自定义的,不在上面三个里面的规则

举些例子:

  • Primary Key (主键)

  • Foreign Key (外键)

  • Not Null

  • Unique

  • ...

Consistency,一致性,我认为就是需要数据库里面的数据在时间上是一致的,比如1分钟前插入的数据和1分钟之后插入的数据都是满足同一套约束条件的。
所谓一致,即满足同一套规则。

K:  一致,约束,同一套规则

Q:  Isolation是什么?

A: WIKI

Isolation is typically defined at database level as a property that defines how/when the changes made by one operation become visible to other.

翻译:
隔离性,是指数据库里面的一个操作产生的影响如何/什么时候对另一个操作可见。
这里有些断章取义的意味,更合适的,我认为应该是:
隔离性,规定了什么时候,一个事务产生的影响如何对另一个事务可见。

Isolation牵涉到两个概念:

  • Concurrency Control。并发控制,往往通过加锁的方式对并发操作进行一定的控制

  • Isolation Levels。隔离级别,由高到低分为四种:

    • Serializable, 串行,即两个事务不能同时执行,只有一个执行完成之后,才执行另一个

    • Repeatable reads, 可重复读

    • Read committed, 提交读,简单来说,就是提交了的数据才能读到

    • Read uncommitted, 未提交读,即未提交的数据也能读到

committed的意思就是提交,一般表示一个事务的结束。

Read Uncommitted: 直接翻译一下就是读取了未提交的数据,即事务A在进行操作的时候,事务B对数据产生的改动会被A直接读取到。这样的影响在于:事务A读取到的事务B产生的改动是不安全的,因为该改动可能被事务B回滚。这种情况,称为“脏读”,即读取了脏数据(事务B产生的改动)。

Read Committed: 直译就是读取的是已提交的数据。显而易见,这可以避免上面提到的脏读。然而,这样也有问题。其场景为:事务A在一个事务中需要两次读取同一条数据,在读取的间隙,事务B对该数据进行了改动,然后提交了。此时会造成事务A
两次读取到的数据不一样,虽然按道理应该是一样的。这样的问题,称为“不可重复读”

Repeatable Reads: 直译为可重复读。即保证了同一事务中两次读取的数据是一致的。即在事务开始之后,其他事务对数据的改动对该事务不可见。这时候出现的问题是,如果事务A中两次进行了范围查询(比如select * from user where age > 10),在两次查询之间,事务B插入了一条满足查询的数据,那么事务A中两次范围查询的结果不一样。此时事务A感觉出现了幻觉,这种情况,我们称为幻读。

Serializable:事务串行执行,可以解决上面提到的“脏读”、“不可重复读”、“幻读”问题,然而代价是不支持并行,性能差。

鉴于比较繁琐,列个表:

事务级别可能出现的问题出现问题的场景造成的影响
Read Uncommitted脏读事务A读取了事务B即将回滚的数据读取了错误的数据
Read Committed不可重复读事务A进行了两次数据读取,读取间隙,该数据被事务B改动且提交了两次读取内容不一样,可能造成操作出错
Repeatable Reads幻读事务A进行了两次范围读取,读取间隙,该范围被事务B插入了数据且提交了两次读取内容不一样,可能造成操作出错
Serializable串行执行性能低

K: 多个事务,影响可见,隔离级别
R:
Q: 各个事务级别如何实现?

Q: 各个事务级别如何实现?

A: 大约有两种方式:

  • 多版本并发控制(MVCC,Multi-Version Concurrency Control)

先来看看锁的实现方式。这里我们使用Mysql的一些定义[6],锁可以分为两种:

  • 共享锁(shared(s) lock),多个事务可以共享

  • 排他锁(exclusive(x) lock),同一时间,只能一个事务可以持有

一般来说:

  • 读取数据的时候,需要获取共享锁,即s锁

  • 修改或者删除数据的时候,需要获取排他锁

此处考虑两种情况及其处理方式:

  • 假设事务T1持有对行r的一个s锁,此时另一个事务T2需要对r行进行操作:

    • 事务T2希望获取s锁,此时可以立即获取到s锁

    • 事务T2希望获取x锁,此时无法立即获取到(需要等待之前的s锁被释放。有没有可能多个事务一直对某行加s锁,而一个想获取到x锁的事务一直都无法得到x锁(starving problem)?此时可以考虑请求锁的顺序,比如将锁的请求放到一个队列里面,先进先出。)

  • 假设事务T1持有对行r的一个x锁,此时另一个事务T2需要对r行进行操作:

    • 事务T2希望获取s锁,无法立即获取,需要等待x锁释放

    • 事务T2希望获取x锁,无法立即获取,需要等待x锁释放

可能的实现方式(读写前获取锁,事务结束之后释放锁):

隔离级别读写锁实现
Read Uncommitted无需任何锁
Read Committed写锁等待读锁全部被释放,表明所有读操作完成。
写锁排斥读锁,因此写入的时候没有任何读操作
Repeatable Read同上,由于写入的同时保证了没有事务在进行读取,因此不会出现不可重复读
Serializable全都用排他锁咯

MVCC可以归纳为snapshot(快照)的其中一种。
为什么要使用MVCC?

最早的数据库系统,只有读读之间可以并发,读写,写读,写写都要阻塞。引入多版本之后,只有写写之间相互阻塞,其他三种操作都可以并行,这样大幅度提高了InnoDB的并发度。
---------http://mysql.taobao.org/monthly/2017/12/01/

隔离级别读写锁实现
Read Uncommitted不支持
Read Committed读取之前获取快照,写锁并不需要等待读锁,读锁也不需要等待写锁的释放
事务读取的是快照,因此不会读取到事务未提交的数据
Repeatable Read事务一开始的时候就获取快照
Serializable不支持

Q: Durability是什么?

A: WIKI

In database systems, durability is the ACID property which guarantees that transactions that have committed will survive permanently.



作者:Mr_Hospital
链接:https://www.jianshu.com/p/b8f6ce2cc9b4


点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消