关于 MySQL 事物的介绍

本文主要是介绍关于 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 的原因

1. MySQL 5.1 之前 Binlog 只有 STATEMENT 格式，在 RC 隔离级别下面，日志格式可能和指向顺序不一致。
2. 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这个命令。

一致性视图创建时机

• 读已提交：每个语句执行前都会重新算出一个新的视图
• 可重复读：事物开始时候创建

数据是否可见：

1. 版本未提交，不可见。
2. 版本已提交，但是在视图创建后提交，不可见。
3. 版本已提交，但是在视图创建前提交，可见。

一致性实现

一致性是指事务执行结束后，数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。数据库的完整性约束包括但不限于：实体完整性（如行的主键存在且唯一）、列完整性（如字段的类型、大小、长度要符合要求）、外键约束、用户自定义完整性（如转账前后，两个账户余额的和应该不变）。

一致性是事物追求的最终目标，实现一致性的措施包括：

• 保证原子性、持久性和隔离性，如果这些特性无法保证，事务的一致性也无法保证
• 数据库本身提供保障，例如不允许向整形列插入字符串值、字符串长度不能超过列的限制等
• 应用层面进行保障，例如如果转账操作只扣除转账者的余额，而没有增加接收者的余额，无论数据库实现的多么完美，也无法保证状态的一致

这篇关于关于 MySQL 事物的介绍的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---