ACID 特性
在关系型数据库管理系统中,一个逻辑工作单元要成为事务,必须满足这 4 个特性,即所谓的 ACID:
原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)。
原子性
原子性:事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。
修改—》Buffer Pool修改—》刷盘。可能会有下面两种情况:
- 事务提交了,如果此时Buffer Pool的脏页没有刷盘,如何保证修改的数据生效? Redo
- 如果事务没提交,但是Buffer Pool的脏页刷盘了,如何保证不该存在的数据撤销?Undo
每一个写事务,都会修改BufferPool,从而产生相应的Redo/Undo日志,在Buffer Pool 中的页被刷到
磁盘之前,这些日志信息都会先写入到日志文件中,如果 Buffer Pool 中的脏页没有刷成功,此时数据
库挂了,那在数据库再次启动之后,可以通过 Redo 日志将其恢复出来,以保证脏页写的数据不会丢
失。如果脏页刷新成功,此时数据库挂了,就需要通过Undo来实现了。
持久性
**持久性:**指的是一个事务一旦提交,它对数据库中数据的改变就应该是永久性的,后续的操作或故障不
应该对其有任何影响,不会丢失。
如下图所示,一个“提交”动作触发的操作有:binlog落地、发送binlog、存储引擎提交、flush_logs,
check_point、事务提交标记等。这些都是数据库保证其数据完整性、持久性的手段。
MySQL的持久性也与WAL技术相关,redo log在系统Crash重启之类的情况时,可以修复数据,从而保
障事务的持久性。通过原子性可以保证逻辑上的持久性,通过存储引擎的数据刷盘可以保证物理上的持
久性。
隔离性
**隔离性:**指的是一个事务的执行不能被其他事务干扰,即一个事务内部的操作及使用的数据对其他的并
发事务是隔离的。
InnoDB 支持的隔离性有 4 种,隔离性从低到高分别为:读未提交、读提交、可重复读、可串行化。锁
和多版本控制(MVCC)技术就是用于保障隔离性的。
一致性
一致性:指的是事务开始之前和事务结束之后,数据库的完整性限制未被破坏。一致性包括两方面的内
容,分别是约束一致性和数据一致性。
**约束一致性:**创建表结构时所指定的外键、Check、唯一索引等约束,可惜在 MySQL 中不支持
Check 。
**数据一致性:**是一个综合性的规定,因为它是由原子性、持久性、隔离性共同保证的结果,而不是
单单依赖于某一种技术。
一致性也可以理解为数据的完整性。数据的完整性是通过原子性、隔离性、持久性来保证的,而这3个
特性又是通过 Redo/Undo 来保证的。逻辑上的一致性,包括唯一索引、外键约束、check 约束,这属
于业务逻辑范畴。
ACID 及它们之间的关系如下图所示,4个特性中有3个与 WAL 有关系,都需要通过 Redo、Undo 日志
来保证等。
WAL的全称为Write-Ahead Logging,先写日志,再写磁盘。
事务控制的演进
并发事务
事务并发处理可能会带来一些问题,比如:更新丢失、脏读、不可重复读、幻读等。
-
更新丢失
当两个或多个事务更新同一行记录,会产生更新丢失现象。可以分为回滚覆盖和提交覆盖。 -
回滚覆盖:一个事务回滚操作,把其他事务已提交的数据给覆盖了。
-
提交覆盖:一个事务提交操作,把其他事务已提交的数据给覆盖了。
-
脏读
一个事务读取到了另一个事务修改但未提交的数据。 -
不可重复读
一个事务中多次读取同一行记录不一致,后面读取的跟前面读取的不一致。 -
幻读
一个事务中多次按相同条件查询,结果不一致。后续查询的结果和面前查询结果不同,多了或少了
几行记录。
排队
最简单的方法,就是完全顺序执行所有事务的数据库操作,不需要加锁,简单的说就是全局排队。序列
化执行所有的事务单元,数据库某个时刻只处理一个事务操作,特点是强一致性,处理性能低。
排他锁
引入锁之后就可以支持并发处理事务,如果事务之间涉及到相同的数据项时,会使用排他锁,或叫互斥
锁,先进入的事务独占数据项以后,其他事务被阻塞,等待前面的事务释放锁。
注意,在整个事务1结束之前,锁是不会被释放的,所以,事务2必须等到事务1结束之后开始。
读写锁
读和写操作:读读、写写、读写、写读。
读写锁就是进一步细化锁的颗粒度,区分读操作和写操作,让读和读之间不加锁,这样下面的两个事务