MySQL Innodb数据库引擎的事务隔离级别
来源:SegmentFault
时间:2023-01-25 17:23:22 141浏览 收藏
对于一个数据库开发者来说,牢固扎实的基础是十分重要的,golang学习网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《MySQL Innodb数据库引擎的事务隔离级别》,主要介绍了MySQL、事务、InnoDB,希望对大家的知识积累有所帮助,快点收藏起来吧,否则需要时就找不到了!
在MySQL中只有使用了Innodb数据库引擎的数据库或表才支持事务。每执行一条增删改查的sql都是一次事务,只不过autocommit默认是开启的,所以自动提交了。
事务必须满足的4个条件:
原子性(或称不可分割性):一个事务中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚到事务开始前的状态,就像这个事务从来没有执行过一样。
一致性:在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则,这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
隔离性(又称独立性):数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括读未提交(Read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串行化(Serializable),这也是本文章要讲的内容。
- 持久性:事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。
多事务并发的问题
当有多个事务并发操作数据库表的时候,可能会出现以下问题:
脏读(读取未提交的数据):脏读又称无效数据的读出,是指在数据库访问中,事务 A 对一个值做修改,事务 B 读取这个值,但是由于某种原因事务 A 回滚撤销了对这个值得修改,这就导致事务 B 读取到的值是无效数据。
时间 事务A 事务B t1 开启事务 开启事务 t2 查询张三账户余额为0 t3 给张三转账1000 t4 查询张三账户余额为1000(脏读) t5 发现转错,撤回1000 t6 提交事务 提交事务 不可重复读(前后数据多次读取,结果集内容不一致):不可重复读即当事务 A 按照查询条件得到了一个结果集,这时事务 B 对事务 A 查询的结果集数据做了修改操作,之后事务 A 为了数据校验继续按照之前的查询条件得到的结果集与前一次查询不同,导致不可重复读取原始数据。
时间 事务A 事务B t1 开启事务 开启事务 t2 查询张三账户余额为0 查询张三账户余额为0 t3 给张三转账1000 t4 提交事务 t5 查询张三账户余额为1000(不可重复读) t6 提交事务 幻读(前后数据多次读取,结果集数量不一致):幻读是指当事务 A 按照查询条件得到了一个结果集,这时事务 B 对事务 A 查询的结果集数据做新增操作,之后事务 A 继续按照之前的查询条件得到的结果集平白无故多了几条数据。
时间 事务A 事务B t1 开启事务 开启事务 t2 查询张三账户交易次数,返回2次 t3 张三按摩消费888,交易次数+1 t4 提交事务 t5 查询张三账户交易次数,返回3次(幻读) t6 提交事务
很多人容易搞混不可重复读和幻读,确实这两者有些相似:一个是结果内容不同;一个是结果数量不同。但不可重复读重点在于update和delete,而幻读的重点在于insert,且两者的解决方法也大有不同。
如果使用锁机制来解决问题,在可重复读中,update sql第一次读取到数据后,就将这些数据加行锁,其它事务无法修改这些数据,就可以实现可重复读了。但这种方法却无法锁住insert的数据,所以不能通过行锁来避免幻读,需要用到表锁或者间隙锁,但会极大的降低数据库的并发能力。
事务的隔离级别
针对上述脏读、不可重复读和幻读三个问题,数据库大佬们提出了一个解决思路,也就是我们本文的主角——事务隔离。
事务隔离由低到高分为四个级别:
读未提交(Read uncommitted):读若不显式声明是不加锁的,可以读取到另一个事务未提交的数据修改,没有避免脏读、不可重复读、幻读。
读已提交(Read committed):一个事务只能读取到另一个事务已经提交的数据修改,这种隔离级别避免了脏读,但是可能会出现不可重复读、幻读。
可重复读(Repeatable read):保证了同一事务下多次读取相同的数据返回的结果集是一样的,这种隔离级别解决了脏读和不可重复读问题,但是仍有可能出现幻读。
- 可串行化(Serializable):对同一数据的读写全加锁,即对同一数据的读写全是互斥了,数据可靠行很强,但是并发性能不忍直视。这种隔离级别虽然解决了上述三个问题,但是牺牲了性能。
Innodb事务隔离的实现
1. Innodb默认隔离级别
在讲事务隔离的实现之前,我们先来了解一下其默认的隔离级别是什么。
Innodb的默认隔离级别是可重复读,可以通过以下两种方式来变更隔离级别:
全局修改,修改mysql.ini配置文件,在最后加上
#可选参数有:READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE. [mysqld] transaction-isolation = SERIALIZABLE
也可通过执行语句改变单个会话或全局的事务隔离级别
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}
然后可以通过以下语句来查询当前隔离级别:
select @@tx_isolation;
2. MVCC
MVCC((Mutil-Version Concurrency Control)),全称多版本并发访问,这是一种并发环境下进行数据安全控制的方法,Innodb通过MVCC来实现提交读(Read committed)和可重复读(Repeatable read)这两种隔离级别。通过MVCC + 锁的方式来实现可串行化(Serializable)隔离级别。
假如有一个表player,你以为它是长这个样子的:
id | name | num |
---|---|---|
1 | kobe | 24 |
但实际上它是长这个样子的:
id | player | num | trx_id | roll_pointer |
---|---|---|---|---|
1 | kobe | 24 | 1 | 指向上一个版本记录的Undo Log日志位置 |
trx_id:只要有任意一个事务对某条聚簇索引记录进行修改,该事务id就会被记录到该字段里面。
roll_pointer:当任意一个聚簇索引记录被修改,上一个版本的数据记录就会被写入Undo Log日志里面。这个roll_pointer就是存储了一个指针,这个指针是一个地址,指向这个聚簇索引的上一个版本的记录位置,通过这个指针就可以获得到每一个历史版本的记录。
Undo log:Undo Log是MySQL的三大日志之一,当我们对记录做了变更操作时就会产生一条Undo记录。它的作用就是保护事务在异常发生的时候或手动回滚时可以回滚到历史版本数据,能够让你读取过去某一个时间点保存的数据。
如果到这里你还有点懵,没事,接下来我们通过一个场景来更直观的感受一下:
有一个事务A,事务id为2,它执行了一下操作
update player set num = 8 where id = 1;
那么,这条记录的trx_id隐藏字段就会记录此次插入记录的事务ID:
这些是不是清晰一点了,其实每一次update或者insert操作,都会写入到Undo Log日志,而读操作只需要根据规则去查看对应的某一个版本,这个规则就是Read View。
Read View 存放着一个列表,这个列表用来记录当前数据库系统中活跃的读写事务,也就是正在进行数据操作但是还未提交保存的事务。其中,有四个重要的字段:
- creator_trx_id:创建当前Read View所对应的事务ID
- m_ids:所有当前未提交事务的事务ID,也就是活跃事务的事务id列表
- min_trx_id:m_ids里最小的事务id值
- max_trx_id:InnoDB 需要分配给下一个事务的事务ID值(事务 ID 是累计递增分配的,所以后面分配的事务ID一定会比前面的大!)
文字总是干巴巴的,下边通过场景,图文并茂的带你了解MVCC是怎样实现可重复读的,以及Read View的作用。
现在两个事务B和C,B的事务id为3,C的事务id为4,还是刚刚的player表:
id | player | num | trx_id | roll_pointer |
---|---|---|---|---|
1 | kobe | 8 | 2 | 指向上一个版本记录的Undo Log日志位置 |
事务B和C将并发做以下操作:
时间 | 事务B | 事务C |
---|---|---|
t1 | 开启事务 | 开启事务 |
t2 | select num from player where id = 1 | |
t3 | update player set num = 10 where id = 1; | |
t4 | 提交事务 | |
t5 | select num from player where id = 1 | |
t6 | 提交事务 |
t1时间,这两个事务就会创建各自的Read View:
事务 B | 事务 C |
---|---|
creator_trx_id = 3 | creator_trx_id = 4 |
m_ids = [3,4] | m_ids = [3,4] |
min_trx_id = 3 | min_trx_id = 3 |
max_trx_id = 5 | max_trx_id = 5 |
t2时间,事务B去读取id=1的数据,找到了记录后就会去查看该记录的trx_id,事务B查看到该记录的trx_id值为2,随后和自己的creator_trx_id值进行比较,发现trx_id = 2 (也是通过此举来实现读已提交隔离级别),这代表本次记录的值是在自己查询之前提交的,便可以读取到num=8。
t3时间,事务C执行了更新操作,并把id=1的trx_id置为4,并把roll_pointer指向trx_id = 2的Undo Log记录。
t4时间,事务C提交,Read View抹除事务C相关数据:
事务 B | - |
---|---|
creator_trx_id = 3 | |
m_ids = [3] | |
min_trx_id = 3 | |
max_trx_id = 5 |
t5时间,事务B再次读取id=1的数据,事务B查看到该记录的trx_id值为4,随后和自己的creator_trx_id值进行比较,发现trx_id = 4 > 自己的creator_trx_id = 3,所以不会直接读取此时的数据,而是通过roll_pointer找到上一个版本,再进行一个trx_id和creator_trx_id的比较,一直找到trx_id
3. 总结
通过以上描述,我们就可以清楚的知道:InnoDB 中,MVCC 就是通过 Undo Log + Read View 进行数据读取,Undo Log 保存了历史快照,而 Read View 规则帮我们判断当前版本的数据是否可见。从而不需要通过加锁的方式,就可以实现提交读和可重复读这两种隔离级别。
那么InnoDB是怎么解决幻读的呢?答案是通过MVCC + 间隙锁(Next-Key Lock),但是极大的降低数据库的并发能力,所以默认的隔离级别设置为不可重复读。
以上就是《MySQL Innodb数据库引擎的事务隔离级别》的详细内容,更多关于mysql的资料请关注golang学习网公众号!
-
499 收藏
-
244 收藏
-
235 收藏
-
157 收藏
-
101 收藏
-
475 收藏
-
266 收藏
-
273 收藏
-
283 收藏
-
210 收藏
-
371 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 542次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 507次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 497次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 484次学习
-
- 难过的玉米
- 这篇文章真是及时雨啊,很详细,受益颇多,已加入收藏夹了,关注老哥了!希望老哥能多写数据库相关的文章。
- 2023-03-07 11:32:49
-
- 洁净的悟空
- 太给力了,一直没懂这个问题,但其实工作中常常有遇到...不过今天到这,看完之后很有帮助,总算是懂了,感谢楼主分享文章!
- 2023-02-23 07:53:26
-
- 威武的老鼠
- 太细致了,码住,感谢师傅的这篇文章,我会继续支持!
- 2023-02-15 12:08:45
-
- 潇洒的铃铛
- 写的不错,一直没懂这个问题,但其实工作中常常有遇到...不过今天到这,帮助很大,总算是懂了,感谢up主分享文章内容!
- 2023-02-04 02:47:34
-
- 陶醉的世界
- 这篇技术贴出现的刚刚好,很详细,很有用,码住,关注老哥了!希望老哥能多写数据库相关的文章。
- 2023-02-04 02:33:53
-
- 高高的蜡烛
- 这篇文章内容太及时了,老哥加油!
- 2023-02-03 18:52:10
-
- 霸气的毛豆
- 很详细,已收藏,感谢作者大大的这篇文章,我会继续支持!
- 2023-01-27 18:09:15
-
- 调皮的薯片
- 这篇技术文章真是及时雨啊,太细致了,太给力了,收藏了,关注up主了!希望up主能多写数据库相关的文章。
- 2023-01-27 08:42:31