本文主要是介绍关于 MySQL 事物的介绍,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
1. 事物的特性
- 原子性(Atomicity,或称不可分割性),要么全部执行,要么不执行
- 一致性(Consistency),执行前后,数据保持完整
- 隔离性(Isolation),事务操作之间彼此独立和透明互不影响。
- 持久性(Durability),修改持久化到磁盘,事务一旦提交,其结果就是永久的。即便发生系统故障,也能恢复。
2. 事物隔离级别
-
读未提交(Read Uncommited),所有事物可以看到其它事物未提交的数据。造成脏读(Dirty Read),即读取到脏数据。
-
读已提交(Read Commited),事物只能看到其它事物提交的结果。这里会存在不可重复读的问题;事物 A 在事物 B 提交前、提交后读取相同的行数据,结果可能不一样。
每一条 select 都有自己的一致性读 ReadView
-
可重复读(Repeatable Read),MySQL 默认事物隔离级别,同一事务的多个实例在并发读取数据时,会看到相同的数据行。
ReadView 是以第一条 select 语句的运行时,作为本事务的一致性读 snapshot 的建立时间点
-
串行化(Serializable),强制事务排序,使之不可能出现冲突。在读取的数据行上面加上共享锁
可重复读的核心就是一致性读(consistent read);而事务更新数据的时候,只能用当前读。如果当前的记录的行锁被其他事务占用的话,就需要进入锁等待。
而读提交的逻辑和可重复读的逻辑类似,它们最主要的区别是:在可重复读隔离级别下,只需要在事务开始的时候创建一致性视图,之后事务里的其他查询都共用这个一致性视图;在读提交隔离级别下,每一个语句执行前都会重新算出一个新的视图。
2.1 MySQL 默认隔离级别是 RR 的原因
- MySQL 5.1 之前 Binlog 只有 STATEMENT 格式,在 RC 隔离级别下面,日志格式可能和指向顺序不一致。
- 5.1 之后,Binlog 支持 ROW 模式,主从复制就不会出现这样问题
所以使用 RR 是为了兼容 5.0 之前的 MySQL 版本 Binlog 日志有问题的场景;、
3. 并发事物带来的问题
-
脏读(Dirty Read):一个事务可以读取其他事务未提交的执行结果
-
丢失修改(Lost to modify):第一个事务中修改了这个数据后,第二个事务也修改了这个数据。
-
不可重复读(Nonrepeatable Read):在同一次事务中,同一个查询在 T1 时间内读取某一行,在 T2 时间重新读取这一行,这一行发生了 UPDATE 或者 DELETE。
-
幻读(Phantom Read):用户读取某一范围的数据行时,另外一个事务在范围内 插入 insert 了新行,用户再次读取时,发现新的幻影行(第二次查询返回了第一次查询没有返回的行)。Phantom Rows
不可重复读重点在于 update 和 delete,数据发生了变化,而幻读的重点在于 insert(行数发生了变化)。
InnoDB 通过多版本并发控制(MVCC,Multiversion Conccurrency Control)解决不可重复读问题,在此基础上通过间隙锁解决幻读问题。
4. 事物的实现
4.1 原子性实现:undo log
undo log 属于逻辑日志,记录 SQL 执行相关信息,记录的是与操作相反的操作,insert 对应 delete
4.2 持久性实现:redo log
InnoDB 提供 Buffer Pool 作为数据库缓存,读取数据从 Buffer Pool 中读取,若 Buffer Pool 没有再去磁盘中读取并放入 Buffer Pool;当数据发生修改时,会先在 redo log 中记录此次操作,然后修改 Buffer Pool 数据(WAL,Write ahead logging,预写式日志),避免 MySQL 宕机后,Buffer Pool 中数据没有 flush 到磁盘中。
4.3 隔离性实现
隔离性追求的目标是并发情形下事物之间的操作互不干扰,
- 事物 A 的写操作对事物 B 的写操作隔离:锁机制
- 事物 A 的写操作对事物 B 的读操作隔离:MVCC 机制
5. 锁
事物在修改数据之前,先获取相应锁才能修改数据,其它事物只能等待该事物操作完成or回滚完成之后,获取锁才能修改数据。
6. 多版本并发控制 Multi-Version Concurrency Control(MVCC)
MVCC 仅在 RC 和 RR 隔离级别下面起作用
当读取的某一行被其他事务锁定时,它可以从 undo log 中分析出该行记录以前的数据是什么,从而提供该行版本信息,帮助用户实现一致性非锁定读取。
1)隐藏列:InnoDB中每行数据都有隐藏列,隐藏列中包含了本行数据的事务id(DATA_TRX_ID)、指向 undo log 的指针(DATA_ROLL_PTR),若没有主键还会有 DB_ROW_ID
2)基于undo log 的版本链:前面说到每行数据的隐藏列中包含了指向 undo log 的指针,而每条undo log 也会指向更早版本的 undo log,从而形成一条版本链。
3)ReadView:通过隐藏列和版本链,MySQL 可以将数据恢复到指定版本;但是具体要恢复到哪个版本,则需要根据 ReadView 来确定。所谓ReadView,是指事务(记做事务A)在某一时刻给整个事务系统(trx_sys)打快照,之后再进行读操作时,会将读取到的数据中的事务 id 与 trx_sys 快照比较,从而判断数据对该 ReadView 是否可见,即对事务 A 是否可见。
trx_sys中的主要内容,以及判断可见性的方法如下:
- low_limit_id:表示生成 ReadView 时系统中应该分配给下一个事务的id。如果数据的事务 id 大于等于 low_limit_id ,则对该 ReadView 不可见。
- up_limit_id:表示生成 ReadView 时当前系统中活跃的读写事务中最小的事务 id。如果数据的事务 id 小于 up_limit_id,则对该 ReadView 可见。
- rw_trx_ids:表示生成 ReadView 时当前系统中活跃的读写事务的事务 id 列表。如果数据的事务 id 在 low_limit_id 和 up_limit_id 之间,则需要判断事务 id 是否在 rw_trx_ids 中:如果在,说明生成 ReadView 时事务仍在活跃中,因此数据对 ReadView 不可见;如果不在,说明生成 ReadView 时事务已经提交了,因此数据对 ReadView 可见。
概览梳理
begin/start transaction 命令并不是一个事物的起点,在执行到他们之后的第一个操作 InnoDB 表的语句,事物才真正启动(即执行一个快照读语句时创建)。若想马上启动一个事物,可以使用start transaction with consistent snapshot
这个命令。
一致性视图创建时机
- 读已提交:每个语句执行前都会重新算出一个新的视图
- 可重复读:事物开始时候创建
数据是否可见:
- 版本未提交,不可见。
- 版本已提交,但是在视图创建后提交,不可见。
- 版本已提交,但是在视图创建前提交,可见。
一致性实现
一致性是指事务执行结束后,数据库的完整性约束没有被破坏,事务执行的前后都是合法的数据状态。数据库的完整性约束包括但不限于:实体完整性(如行的主键存在且唯一)、列完整性(如字段的类型、大小、长度要符合要求)、外键约束、用户自定义完整性(如转账前后,两个账户余额的和应该不变)。
一致性是事物追求的最终目标,实现一致性的措施包括:
- 保证原子性、持久性和隔离性,如果这些特性无法保证,事务的一致性也无法保证
- 数据库本身提供保障,例如不允许向整形列插入字符串值、字符串长度不能超过列的限制等
- 应用层面进行保障,例如如果转账操作只扣除转账者的余额,而没有增加接收者的余额,无论数据库实现的多么完美,也无法保证状态的一致
这篇关于关于 MySQL 事物的介绍的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!