当前位置：首页 > news >正文

10.MySQL事务

news 来源：原创 2025/7/26 14:04:24

什么是事务
为什么有事务存在
事务的版本支持
事务的提交方式
事务常见的操作方式
事务异常验证与产出结论
事务隔离性理论
事务隔离级别的设置与查看
事务隔离级别 - 读未提交
事务隔离级别 - 读提交
事务隔离级别 - 可重复读
事务隔离级别 - 串行化
MVCC机制
- 3个记录隐藏字段
- undo日志
- Read View理论
RC 和 RR 的本质区别

什么是事务

如果CURD不加控制, 会有什么问题 ?

当客户端A检查还有一张票时, 将票卖掉, 还没有执行更新数据库时, 客户端B检查了票数, 发现大于0, 于是又卖了一次票. 然后A和B再将票数更新到数据库. 这时就出现了同一张票被卖了两次. 这是不满足正常业务逻辑的. 我们希望如果失败了, 就会有中间状态, 就需要回滚到最开始的状态.
日常生活中除了这种场景, 转账也是一样的. 转账的时候, 我的钱减了100, 但是这个操作还没做完, 网络出现问题, 数据库出问题, 各种原因导致没有给你加上100, 整个操作就会出现一个中间过程, 中间过程是运行异常产生, 一旦出现问题了, 如果对应的操作没有完成, 把减掉100再加回来, 就好像没什么都没做. 这就是回滚操作

所以我们希望CURD满足一些属性, 才能解决上述的问题:

买票的过程是原子的, 要么不抢, 要么抢到就有票, 类似于没有中间状态.
买票互相不能影响, 我在买票的时候, 我购买的行为不会影响到你的购票行为
买完票应该要永久有效
买前和买后都要是确定的状态

再回到上面的问题: 什么是事务?
事务就是一组DML(数据管理语言)语句组成, 这些语句在逻辑上存在相关性, 这一组DML语句要么全部成功, 要么全部失败, 是一个整体.
大白话说就是由一条或者多条sql语句共同构成的一个sql的集合体, 这个集合体在一起共同要完成某种任务, 执行结果就两种, 要么都成功, 要么都失败, 不会出现某些成功, 某些失败的情况.

一个完整的事务, 绝对不是简单的sql集合(DML), 还需要满足以下四个属性:
原子性: 一个事务(transaction)中的所有操作, 要么全部完成, 要么全部不完成, 不会结束在中间某个环节. 事务在执行过程中发生错误, 会被回滚(Rollback)到事务开始前的状态, 就像这个事务从来没有执行过一样
一致性: 在事务开始之前和事务结束之后, 数据的完整性没有被破坏.
什么是数据的完整性?
大白话说就是一种状态到另一种状态结果是可预期的, 比如我给你转账, 你有50, 我有200, 我给你转100, 成功了, 预期你有150, 我有100, 失败了你还是50, 我还是200, 这就是回到了未操作前的状态, 这结果是可预期的. 严谨的说法: 写入的资料必须完全符合所有的预设规则, 这包含资料的准确度, 串联性以及后续数据库可以自发性的完成预定的工作.
隔离性: 数据库允许多个并发事务同时对齐数据进行读写和修改的能力, 隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致.
事务隔离分为不同级别, 包括读未提交(Read uncommitted), 读提交(read committed), 可重复读(repeatable read)和串行化(Serializable) – 隔离级别会在后面讲到
持久化: 事务处理结束后, 对数据的修改就是永久的, 即便系统故障也不会丢失.

一句话总结: 什么叫事务?
事务就是在ACID四大属性的加持下, 由一条或者多条sql共同构建的, 就叫做事务.

为什么有事务存在

事务被MySQL编写者设计出来, 本质是为了应用程序访问数据库的时候, 事务能够简化我们的编程模型, 不需要我们去考虑各种各样的潜在错误和并发问题. 这就使我们使用事务时, 要么提交, 要么回滚, 我们就不会去考虑网络异常, 服务器宕机, 同时修改一个数据了会怎么办. 因此事务本质上就是为了应用服务的.

事务的版本支持

在 MySQL 中只有使用了 InnoDB 数据库引擎的数据库或表才支持事务, MyISAM不支持.

查看数据库引擎

事务的提交方式

事务的提交方式常见的有两种:
1. 自动提交
2. 手动提交

查看事务提交方式

可以看到我们自动提交是on, 默认是打开的.

用 SET 来改变 MySQL 的自动提交模式

事务常见的操作方式

准备工作:

准备好mysql的客户端和服务器

客户端程序不仅仅可以是这种命令行的客户端, 还可以是图像化界面版的, 还可以编写代码时的C/C++语言版的

为了便于延时, 我们将mysql的默认隔离级别设置成读未提交.

我们不是将隔离界别设置为了读未提交吗, 为什么显示的是可重复读呢?
原因是我们需要重启客户端.

为什么先要怎么设置?
1.为了研究事务, 就要研究多个客户端并发访问的情况, 所以新起两个mysql客户端来对比, 来充当并发访问mysql服务的客户端, 来制作出很多的并发场景, 这样就能方便我们的研究, 很清楚的看到双方在交叉访问时产生的问题.
2.原来默认的隔离性太高了, mysql隔离级别调成最低, 这边操作, 另一边就立马能看到, 如果调成最高的话, 这边操作者完, 另一边都看不到对方.

操作演示:

查看有几个客户端连接到了mysql服务器

我们现在有两个客户端连接到了mysql服务器, 均是读未提交的隔离级别, 下面开始正式进行操作演示

客户端A创建一个表后, 另一边客户端B能立刻看到

证明事务的开始与回滚

是不是必须要设置保存点才可以进行回滚呢?

可以看出来不是, 可以直接rollback进行回滚

回滚操作只有在事务运行期间进行操作

事务异常验证与产出结论

如果在事务运行期间出问题了呢?

commit提交后客户端崩溃了会发生什么

我们begin commit,这叫做手动提交, 而手动提交事务和该事务自动被提交是两码事, 这两个并不会互相影响.

自动提交影响了什么, 后面再说, 但我们知道了自动提交不影响我们手动begin, commit

我们以前写单sql语句和子查询CURD的时候, 我们从来没有写过begin, commit这样的代码. 以前的sql和我们现在的事务之间是什么关系?

证明单条SQL与事务的关系

总结:
1.autocommit会影响我们的单sql, 每一条sql就相当于一个事务, 每一个sql执行的时候会被打包成事务, 虽然你没有写begin和commit, 但你的单sql实际上执行了begin和commit.
2.当你的单sql在执行的时候autocommit是off的, 执行sql的时候就相当于事务begin了, 但是你没有commit, 只是事务执行中, 当客户端崩掉了, 会导致数据自动回滚.
3.我们以前执行的单条sql全部都是单sql的事务, 这些事务因为是自动提交的, 所以我们感知不到.

结论:

只要输入begin或者start transaction, 事务变必须要通过commit提交, 才会持久化, 与是否设置set autocommit无关.
在事务运行期间, 事务可以手动回滚, 同时, 当操作异常, MySQL会自动回滚
对于InnoDB每一条SQL语言都默认封装成事务, 自动提交. (select有特殊情况, 因为MySQL有MVCC机制, 后面会讲)

事务操作注意事项:

如果没有设置保存点, 也可以回滚, 只能回滚到事务的开始. 直接使用rollback前提是在事务运行期间.
如果一个事务被提交了(commit), 则不可以回退(rollback)
可以选择回退到哪个保存点
InnoDB支持事务, MyISAM不支持事务
开始事务可以使用start transaction或者begin

事务隔离性理论

从上面的例子, 我们能看到实物本身的原子性(回滚), 持久性(commit后, 被写入到磁盘了, 不会回滚了)
那么隔离性?一致性呢? 什么叫隔离性, 什么叫隔离级别? 为什么会有这么多隔离级别?

如何理解隔离性:

MySQL服务器作为服务器, 可能被多个MySQL客户端同时进行并发访问. 所有事务都有一个执行过程, 那么在多个事务各自执行多个SQL的时候, 就可能会出现互相影响的情况, 就如开篇讲的抢票例子.
数据库中, 为了保证事务执行过程中尽量不受干扰, 就有了一个重要特征: 隔离性.
数据库中, 允许事务收不同程度的干扰, 就有了一种重要特征: 隔离级别.

举个例子帮助理解:
比如你朋友转账给你, 你去查你的账户, 你先去查, 因为网络很慢, 所以查的比较久, 你朋友在你查的时候转账完了, 你才查到结果, 因为你是在你朋友之前查的, 所以你查到的是你朋友还未转账的情况, 如果你查到的是转账后的情况, 则说明影响到你了, 因为你是在转账之前查询的, 所以你的查询预期结果应该是未转账的. 这就是影响

隔离级别:

读未提交(Read Uncommitted): 在该隔离级别, 所有的事务都可以看到其他事务没有提交的执行结果. (实际生产中不可能使用这种隔离级别的), 这相当于没有隔离性, 所以就会有很多并发问题, 如脏读, 幻读, 不可重复读等, 我们上面为了做实验方便, 用的就是这个隔离性.
读提交(Read Committed): 它满足了隔离的简单定义: 一个事务只能看到其他已经提交的事务所做的改变. 但是会有不可重复读的问题
可重复读(Repeatable Read): 这是MySQL的默认隔离级别, 它确保同一个事务, 在执行中, 多次读取操作数据时, 会看到同样的数据行. 但是会有幻读问题.
串行化(Serializable): 这是事务的最高隔离级别, 它通过强制事务排序, 串行化执行所有事务, 使值不可能互相冲突.从而解决了幻读问题.它在每个读的数据行上面加上共享锁，但是可能会导致超时和锁竞争(这种隔离界别太极端, 实际生产基本不使用)

事务隔离级别的设置与查看

查看全局隔离级别

查看会话(当前)全局隔离级别

设置当前会话 or 全局隔离级别语法

SET [SESSION |GLOABAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

事务隔离级别 - 读未提交

一个事务在执行中, 读到另一个执行中事务的更新(或其他操作) 但是未commit的数据, 这种现象叫做脏读(dirty read)

事务隔离级别 - 读提交

为什么修改了还是读未提交? 需要重启会话

这就是读提交的隔离级别, 可以看到有一个问题, 客户端B的事务还在运行的时候, 同样调用select语句得到了不同的结果, 这种现象叫做不可重复读

不可重复读, 是问题吗? 因为是原子的, 所以在同一个事务内查到的结果应该是一样的. 下面来举个例子来说明不可重复读是有问题的.
如果财务在统计工资的时候, 在2000-3000的之间统计(select name from emp where sal >= 2000 and sal < 3000)了一批人(包括你), 记录了下来, 很巧在这期间你让老板给你涨了工资, 工资涨到了4000-5000之间, 财务在4000-5000之间统计(select name from emp where sal >= 4000 and sal < 5000)了一批人(又包括了你), 财务发工资的时候, 拿着这个统计表发工资, 2000-3000给你发了一份, 在4000-5000又给你发了一份工资, 一共给你发了两份工资, 所以这是有问题的

事务隔离级别 - 可重复读

重启mysql服务器会恢复到默认的隔离级别 - 可重复读

一般的数据库在可重复读情况的时候, 无法屏蔽其他事务insert数据. 因为隔离性实现是对数据加锁完成的, 而insert待插入的数据因为不存在加锁, 所以一般加锁无法屏蔽这类问题. 可重复读多次查找时, 会多查找出来新的记录, 就如同产生了幻觉. 这种现象, 叫做幻读.
mysql5.7以上的版本在RR级别下, 是解决了幻读的情况的. 解决的方式是用Next-Key锁(GAP + 行锁)解决的. 有兴趣可以自行看一些文章

事务隔离级别 - 串行化

串行化的表现: 彼此之间互不影响, 但保证读写并发

具体加锁原理是什么呢?

隔离级别	脏读	不可重复读	幻读	加锁读
读未提交(read uncommitted)	会发生	会发生	会发生	不加锁
读已提交(read committed)	不会发生	会发生	会发生	不加锁
可重复读(repeatable read)	不会发生	不会发生	不会发生	不加锁
可串行化(serializable)	不会发生	不会发生	不会发生	加锁

MVCC机制

数据库并发的场景有三种:

读-读: 不存在任何问题, 也不需要并发控制.
读-写: 有线程安全问题, 可能会造成事务隔离性问题, 可能遇到脏读, 幻读, 不可重复读
写-写: 有线程安全问题, 可能会存在更新丢失问题, 比如第一类更新丢失, 第二类更新丢失(后面补充)

MVCC是一种用来解决读 - 写冲突的无锁并发控制, 事务是原子的, mysql为了解决事务执行中的并发问题, 让事务有先有后, 具体它是怎么处理这个事务有先有后的呢? 下面就是我们要学习的第一个知识点:
MySQL会为事务分配单向增长的事务ID, 为每个修改保存一个版本, 版本与事务ID关联. 一般而言, 数字越小, 来的越早, 所以可以通过ID来判断事务的先后顺序.

理解MVCC需要知道三个前提知识:

3个记录隐藏字段
undo 日志
Read View

3个记录隐藏字段

DB_TRX_ID: 最近修改事务ID, 记录创建这条记录/最后一次修改该记录的事务ID.
DB_ROLL_PTR: 回滚指针, 指向这条记录的上一个版本(当一个事务要修改某一行的时候, 实际上会产生一个副本, 你真正改的是这个副本, 这样就能在这个事务改完后, 如果后悔了, 就可以回滚到这个历史版本, 这和之前的写时拷贝策略很像, 修改的时候会拷贝一份, 我们修改的是拷贝的这一份)
DB_ROW_ID: 隐含的自增ID(隐藏主键), 如果数据表没有主键, InnoDB会自动生成一个隐藏主键, 并且以该隐藏主键产生一个聚簇索引(B+树). (如果自己声明有主键, 则该隐藏的不会存在, 就理解为缺省的)
补充: 实际还有一个flag隐藏字段, 删除并不是真正的删除数据, 而是flag改变了.

下面来举个例子:

实际上我们还会查询到三个隐藏字段

name age DB_TRX_ID(创建该记录的事务ID) DB_ROW_ID(隐藏主键) DB_ROLL_PTR(回滚指针)
张三 28 创建该记录的事务ID 1 null(因为该记录没有历史数据)

name	age	DB_TRX_ID(创建该记录的事务ID)	DB_ROW_ID(隐藏主键)	DB_ROLL_PTR(回滚指针)
张三	28	创建该记录的事务ID	1	null(因为该记录没有历史数据)

undo日志

MySQL将来是以服务进程的方式, 在内存中运行. 我们之前所讲的所有机制: 索引, 事务, 隔离性, 日志等, 都是在内存中完成的, 即在 MySQL 内部的相关缓冲区中, 保存相关数据, 完成各种判断操作. 然后在合适的时候, 将相关数据刷新到磁盘当中的. 所以, 我们这里理解undo log, 简单理解成, 就是MySQL中的一段内存缓冲区, 用来保存历史数据的.

现在事务11和事务10同时来了, 都要对表进行修改, 虽然是同时来, 但总有一个先后顺序, 事务10先来
现在事务10, 对student表中记录进行修改update, 将name(张三)改成name(李四).

上述操作可以简述为1. 加锁 2.写时拷贝 3.修改 4.释放锁
因为事务10一开始就将资源加上锁了, 所以事务10才能顺利的修改数据, 事务11没有干扰到事务10
事务10提交了, 现在事务11, 对student表中记录进行修改update: 将age(28)改成age(38).

这样, 我们就有了一个基于链表记录的历史版本链. 所谓的回滚, 无非就是用历史数据, 覆盖当前数据. 上面的一个一个版本, 我们可以称之为一个一个的快照.
再纠正一点, undo log记录的不是历史的完整数据, 而是记录相反的操作所需的数据. 而我们上面讲的, 更多是为了支持我们的隔离性而设计的.
比如说insert, mysql记录的是相反的操作, 叫做delete, 再回滚的时候, 执行相反的sql就可以了
比如说update，undolog中会记录修改前的旧值，以便在回滚时能够将记录更新为旧值。
比如说delete, delete删数据不是清空, 而是设置flag, 所以delete也是修改.
那select呢? select不会对数据做任何修改, 所以, 为select维护多版本, 没有意义.

select读取, 是读取最新的版本, 还是读取历史版本呢?都有可能
当前读: 读取最新的记录, 就是当前读. 增删改, 都叫做当前读, select可以当前读, 比如: select lock in share mode(共享锁), select for update(这个很好理解, 我们后面不讨论)
快照读: 读取历史版本, 就叫做快照读.

之前的实验告诉我们, 你改完了, 我还是看不到, 说明我们读的一定是不同的数据, 为什么读写可以并发呢? 因为写的是当前数据, 读的是历史版本, 所以两个不会出现访问同一个位置, 所以不需要加锁, 所以就不会出现互相阻塞的情况, 所以就可以并发进行操作.
隔离性的本质: 在版本上做隔离(就叫做mvcc), 你应该看到哪个历史版本, 就有了不同的隔离性, 所以回滚和隔离性都是由mvcc来实现的

我们可以看到, 在多个事务同时删改查的时候, 都是当前读, 是要加锁的. 那同时有select过来, 如果也要当前读, 那么也就需要加锁, 这就是串行化. 串行化: 读写都是进行当前读. (那为什么我看到, 一遍阻塞的时候, 另一边可以读? 因为是用共享锁和排他锁进行加锁的)
如果是快照读, 读取历史版本的话, 是不受加锁限制的. 也就是可以并行执行! 换言之, 提高了效率, 即MVCC的意义所在.

那么是什么决定了, select是当前读, 还是快照读呢? 隔离级别
那为什么要有隔离级别呢? 事务都是原子的. 所以, 无论如何, 事务总有先有后. 那么多个事务在执行中, CURD操作是会交织在一起的. 那么, 为了保证事务的 “有先有后”, 是不是应该让不同的事务看到它该看到的内容,看这就是所谓的隔离性与隔离级别要解决的问题.

为什么隔离级别是RC和RR我们就能看到不同的结果呢?

Read View理论

Read View就是事务进行快照读操作的时候生产的读视图(Read View), 在该事务执行的快照读的那一刻, 会生成数据库系统当前的一个快照, 记录并维护系统当前活跃事务的ID(当每个事务开启时, 都会被分配一个ID, 这个ID是递增的, 所以最新的事务, ID值越大)

Read View 在MySQL源码中, 就是一个类, 本质是用来进行可见性判断的. 事务就像进程PCB, ReadView就像进程地址空间, 互相用指针关联起来就可以判断事务的可见性. 当我们某个事务执行快照读的时候, 对该记录创建一个Read View读视图, 把它比作条件, 用来判断当前事务能够看到哪个版本的数据, 既可能是当前最新的数据, 也有可能是该行记录的undo log里面的某个版本的数据.

下面是ReadView结构, 单位了减少同学们的负担, 我们简化一下:

class ReadView {
// 省略...
private:
trx_id_t m_low_limit_id;	// 高水位, 大于等于这个ID的事务均不可见
trx_id_t m_up_limit_id;		//低水位: 小于这个ID的事务均可见
trx_id_t m_creator_trx_id;	//创建该 Read View 的事务ID
ids_t m_ids;				//创建视图时的活跃事务id列表
trx_id_t m_low_limit_no; 	//配合purge, 标识该视图不需要小于m_low_limit_no的UNDO LOG, 如果其他视图也不需要, 则可以删除m_low_limit_no的UNDO LOG,
bool m_closed;				//标记视图是否被关闭
//省略...
};
m_ids;						//一张列表, 用来维护Read View生成时刻, 系统正活跃的事务ID
up_limit_id;				//记录m_ids列表中事务ID最小的ID
low_limit_id;				//ReadView生成时刻系统尚未分配的下一个事务ID, 也就是目前已出现过的事务ID的最大值+1
creator_trx_id				//创建该ReadView的事务ID

下面我们来看一下当前快照读，应该读取到哪个历史版本的记录(经过AI多次考证)

部分源码:

read view是事务可见性的一个类, 不是事务创建出来就会有read view, 而是这个事务首次进行快照读的时候, mysql形成read view

ReadView实验 - 整体流程:

假设当前有条记录:

当事务2对某行数据执行了快照读, 就会new一个read view对象, 数据库会为该行数据生成一个Read View读视图

//事务2的Read View
m_ids; //1, 3   	 			正在活跃的事务ID
up_limit_id; //1   				记录活跃活跃的事务ID的最小的事务ID
low_limit_id; //4 + 1 = 5, 		系统尚未分配的下一个事务ID
creator_trx_id;// 2

查版本链, 看能看到哪个最新的版本?

查版本链一定是从最新的版本开始
比较步骤:
DB_TRX_ID(4) 和 up_limit_id(1) 大于, 则说明该事务不在第一部分, 继续判断
DB_TRX_ID(4) 和 low_limit_id(5) 小于, 则说明快照的时候, 该事务跑起来了, 在第二部分
m_ids.contains(DB_TRX_ID), 不包含, 说明事务4不在当前的活跃事务中, 已经提交了, 说明可见
故, 事务4的更改, 应该看到. 所以事务2能读到最新数据记录是事务4所提交的版本.

RC 和 RR 的本质区别

设置RR(可重复读)模式下测试:

实验1:

实验2:

RR与RC的本质区别:
在RC级别下, 事务中, 每次快照读都会新生成一个快照和Read View, 而在RR隔离级别下, 则是同一个事务中的第一个快照读才会创建ReadView, 之后的快照读访问的都是同一个ReadView.

总结:
读写就直接可以并发: 可以不加锁, 那是因为有历史版本写, 比如说增删改, 他都是当前读. 而你的select叫做快照读, 读的是历史版本, mysql底层mvcc维护多版本, 所以我们两个访问的压根儿就是不同版本的数据, 那就不需要加锁了.
我们在一个事务内部, 如果我们操作成功了但提交失败了, 需要回滚, 凭什么回滚呢? mysql维护了历史版本链, 所谓的回滚就做两件事: 1. 事务内部对应的事务结构体和ReadView对象全部释放掉 2.将事务曾经修改过的数据恢复成最开始.

目录