事务思维导图

大灰

2022-11-19

浏览量: 9

MYSQL初级知识

事务

数据库初级

MYSQL数据库初级知识——事务

树图思维导图提供《事务》在线思维导图免费制作，点击“编辑”按钮，可对《事务》进行在线思维导图编辑，本思维导图属于思维导图模板主题，文件编号是：0ed3ec6654921a4444aca896ac12fe55

思维导图大纲

事务的基本要素（ACID）

原子性（Atomicity）

一致性（Consistency）

隔离性（Isolation）

持久性（Durability）

并发事务代来的问题

更新丢失（Lost Update）

脏读（Dirty Reads）

不可重复读（Non-Repeatable Reads）

幻读（Phantom Reads）

并发事务代来的问题

更新丢失（Lost Update）

脏读（Dirty Reads）

不可重复读（Non-Repeatable Reads）

幻读（Phantom Reads）

事务隔离级别

Read-Uncommitted（读未提交）

Read-Committed（读已提交）

Repeatable-read（可重复读）

Serializable（可串行化）

查看当前数据库隔离级别

show variables like 'tx_isolation'; 或者 select @@tx_isolation;

show variables like 'transaction_isolation'; 或者 select @@transaction_isolation;

MVCC（多版本并发控制）

MVCC是行级锁的一个变种，但它在很多情况下避免了加锁操作，因此开销更低。虽然实现机制有所不同，但大都实现了非阻塞的读操作，写操作也只是锁定必要的行。MVCC的实现是通过保存数据在某个时间的快照来实现的。不管需要执行多长时间，每个事务看到的数据都是一致的。

MVCC只在Committed Read 和 Repeatable Read 两种隔离级别下工作。

MVCC实现原理

InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现。一列保存了行的创建时间，一列保存行的过期时间（或删除时间）。存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来查询到每行的版本号进行比较。

Repeatable Read 隔离级别下，MVCC工作方式

select

InnoDB只查找创建版本号小于或等于当前事务版本号的数据行，这样可以确保事务读取的行，要么是在开始事务之前已经存在，要么是事务自身插入或修改过的。

过期版本号要么未定义，要么大于当前事务版本号，这样可以确保事务读取到的行在事务开始之前未被删除。

insert

delete

update

举例说明

初始工作

SELECT

UPDATE

DELETE

优缺点

解决不可重复读和幻读的问题；大多数操作都不用加锁，使数据操作简单，性能好。

缺点：每行记录都需要额外的存储空间，需要做更多的行检查工作和一些额外的维护工作。

事务日志

InnoDB使用日志来减少提交事务时的开销。因为日志中已经记录了事务，就无需在每个事务提交时把缓冲池的脏块刷新到磁盘中。

事务修改的数据和索引通常会映射到表空间的随机位置，所以刷新这些变更到磁盘需要很多随机IO。随机IO比顺序IO昂贵得多，因为一个IO请求需要时间把磁头移到正确的位置，然后等待磁盘上读出需要的部分，再转到开始位置。

InnoDB用日志把随机IO变成顺序IO。一旦日志安全写到磁盘，事务就持久化了，即使断电了，InnoDB重启后可以通过redo log恢复以及提交的事务。

InnoDB使用一个后台线程智能地刷新这些变更到数据文件。这个线程可以批量组合写入，使得数据写入更顺序，以提高效率。

事务的实现

事务的实现是基于数据库的存储引擎。不同的存储引擎对事务的支持程度不一样。MySQL 中支持事务的存储引擎有 InnoDB 和 NDB。

事务的实现就是实现ACID特性。事务隔离性是通过锁实现，而事务的原子性、一致性和持久性则通过事务日志实现。

事务日志包括：redo log（重做日志）和undo log（回滚日志）

redo log（重做日志）实现持久化和原子性

在InnoDB存储引擎中，事务日志通过redo log 和日志缓存（InnoDB Log Buffer）实现。

事务开启时，事务中的操作，都会先写入存储引擎的日志缓存中，在事务提交之前，这些缓存的日志都需要提前刷新到磁盘上持久化，这就是“日志先行”（Write-Ahead logging）.

当事务提交之后，在Buffer Pool中影射的数据文件才会慢慢刷新到磁盘。此时如果宕机，那么当系统重启进行恢复时，可以根据redo log中记录的日志，把数据库恢复到奔溃前的一个状态。未完成的事务，可以继续提交或者选择回滚，这基于恢复的策略而定。

在系统启动的时候，就已经为redo log分配了一块连续的存储空间，以顺序追加的方式记录redo log，通过顺序IO改善性能。所有事务共享redo log的存储空间，它们的redo log按语句的执行顺序，一次交替的记录在一起。

redo log 记录示例

undo log（回滚日志）实现一致性

undo log主要为事务的回滚服务。

undo log记录了数据在某个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。

undo log记录的是已部分完成并写入磁盘的未完成（未提交）的事务。

单个事务的回滚，不会影响到其他事务做的操作。

redo log 与 undo log 的区别

两种日志都是为了恢复操作。

redo log是恢复提交事务修改的页操作。而undo log是回滚行记录到特定版本。

两者记录的内容也不同，redo log是物理日志，记录页的物理修改操作。而undo log是逻辑日志，根据每行记录继续记录。

redo + undo log简化过程

假设操作示例

在1-8的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化。若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘。

RBT工作管理计划思维导图