事务的概念
-
一组原子性(即不可拆分)的SQL查询,或者说是一个独立的工作单元
-
事务的概念来自于两个独立的需求:并发数据库访问,系统错误恢复
以一个转账事务为例:某个银行的数据库中有两个表,支票表(Checking)和储蓄表(Savings),现在要从Rocky的支票表转200元到储蓄表;
这个过程包括了以下3个步骤:
(1)检查Rocky的支票账户,余额高于200元
(2)从Rocky的支票账户,- 200元
(3)在Rocky的储蓄账户,+ 200元
上述3个步骤,必须要打包在一个事务中,任何一个步骤失败,则必须回滚所有的事务:
1 START TRANSACTION;
2 SELECT balance FROM Checking WHERE customer_id = 19810301;
3 UPDATE Checking SET balance = balance - 200; —--> 在3、4之间,另一个事务请求,要求清空Rocky的支票账户的所有余额(即并发数据库访问)
4 UPDATE Savings SET balance = balance + 200; ——-> 如果这一条执行时,服务器宕机了(即系统错误恢复)
5 COMMIT;
事务的特性(ACID)
-
A,atomicity 原子性:整个事务中的操作,要么全部提交成功,要么全部失败回滚,不可能只执行其中的一部分操作
-
C,consistency 一致性:数据库总是从一个一致性状态转换到另外一个一致性状态,也就是说事务在未完成时,所有的数据都必须保持一致性的状态
-
I, isolation 隔离性:通常来说,一个事务所做的修改在最终提交前,对另外一个事务是不可见的;事务查看数据时所处的状态,要么是另一个并发事务修改它之前的状态,要么是修改它之后的状态
-
D,durability 持久性:一旦事务提交,其所做的修改就会永久保存到数据库中,即使出现致命的系统故障;但需要注意,持久性不可能是100%
事务的隔离级别
如果不对数据库进行并发控制,可能会产生异常情况:
-
脏读 Dirty Read,当一个事务读取到另一个事务尚未提交的修改时,产生脏读;第一个事务更新了某条数据但尚未提交,此时第二个事务读取到了这条数据,由于有可能第一个事务的操作会被回滚,导致第二个事务读取到的数据是错误的
-
不可重复读 Nonrepeatable Read,一个事务对同一行数据读取了两次,却得到了不同的结果;同一查询在同一次事务中进行多次,由于其他事务所做的修改或删除,导致每次返回不同的结果集,发生非重复读;与脏读不同之处,读发生在事务提交之后(行级锁来解决)
-
幻读 Phantom Read,事务在操作过程中进行两次查询,第二次查询结果包含了第一次查询未出现的数据;当对某行执行插入或删除操作,而该行属于某个事务正在读取行的范围时,产生幻读;与不可重复读不同之处,查询范围不是某一行,而是一个行范围(表级锁来解决)
为了兼顾并发效率和异常控制,在标准SQL规范中,定义了4个事务隔离级别:
-
未提交读 Read Uncommitted(RU),直译就是“读未提交”,意思就是即使一个更新语句没有提交,但是别的事务可以读到这个改变;这个级别会导致很多问题,从性能上来说,也不会比其他级别好太多,除非有非常必要的理由,实际中很少应用
-
已提交读 Read Committed(RC),直译就是"读提交",意思就是语句提交以后,即执行了 Commit 以后别的事务就能读到这个改变,只能读取到已经提交的数据;Oracle等多数数据库默认都是该级别
-
可重复读 Repeatable Read(RR),直译就是"可以重复读",这是说在同一个事务里面先后执行同一个查询语句的时候,得到的结果是一样的;InnoDB和XtraDB存储引擎通过多版本并发控制(MVCC,Multiversion Concurrency Control) 解决了幻读的问题;MySQL数据库默认是该级别
-
串行读 Serializable,直译就是"序列化",意思是说这个事务执行的时候不允许别的事务并发执行;完全串行化的读,每次读都需要获得表级共享锁,读写相互都会阻塞;实际应用中也很少用到这个隔离级别, 只有在非常需要确保数据的一致性而且可以接受没有并发的情况下,才考虑采用 该 级别
隔离级别 | 脏读 | 不可重复读 | 幻读 | 加锁读 |
Read Uncommitted | Yes | Yes | Yes | No |
Read Committed | No | Yes | Yes | No |
Repeatable Read | No | No | Yes | No |
Serializable | No | No | No | Yes |
事务隔离的实现 -- 锁
在处理并发读或者写时,可以通过实现一个由两种类型的锁组成的锁系统来解决问题:
-
读锁 Read Lock,也称共享锁 Shared Lock,读锁是共享的,或者说是相互不阻塞
-
写锁 Write Lock,也称排他锁 Exclusive Lock,写锁是排他的,也就是说一个写锁会阻塞其他读锁或写锁
一种提高共享资源并发性的方式就是让锁定对象更有选择性。尽量只锁定需要修改的部分数据,而不是所有的资源。更理想的方式是,只对会修改的数据片进行精确的锁定。任何时候,在给定的资源上,锁定的数据量越少,则系统的并发程度越高,只要相互之间不发生冲突即可:
-
表锁 Table Lock,表锁是MySQL中最基本的锁策略,并且是开销最小的策略;在特定的场景中,表锁也可能有良好的性能,例如,READ LOCAL 表锁支持某些类型的并发写操作;尽管存储引擎可以管理自己的锁,MySQL本身还是会使用各种有效的表锁来实现不同的目的,例如,服务器会为诸如ALTER TABLE之类的语句使用表锁,而忽略存储引擎的锁机制
-
行锁 Row Lock,行级锁可以最大程度的支持并发处理,同时也带来了最大的锁开销;在Innodb和XtraDB中实现了行级锁;行级锁只在存储引擎层面实现
-
另外,写锁也比读锁有更高的优先级,因此一个写锁请求可能会被插入到读锁队列的前面(写锁可以插入到锁队列中读锁的前面,反之读锁则不能插入到写锁的前面)
参考