mysql事务(包括redo log,undo log,MVCC)及事务实现原理

2024-03-28 05:08

本文主要是介绍mysql事务(包括redo log,undo log,MVCC)及事务实现原理,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

原子性:

一次事务中的所有操作,要么全部完成要么全部不执行。这里是通过undo log来实现的。

undo log又是什么呢,可以理解为要执行的sql的反向sql,也就是回滚sql。譬如你insert了一条,undo log里就会保存一个delete xxx id = xxx。

持久性:

一旦一个事务被提交,就算服务器崩溃,仍然不能丢数据,在下次启动时需要能自动恢复。这里是通过redo log实现的。

那么如何才能持久呢,很简单,写入硬盘就行了。通过前面几篇的学习,我们知道mysql大部分时间是在Innodb_buffer_pool里做内存读写的,特定情况下才会落盘。这样如果突然服务器崩溃,没来得及落盘的数据就会丢失。所以有了redo log顺序写磁盘(顺序写速度极快,后续的落盘是随机写,速度慢),在事务提交后,事务日志会顺序写入磁盘,然后写入pool内存里。然后才是后续的那些按规则将索引数据落盘。

隔离性:

事务的隔离性是通过读写锁+MVCC来实现的。mysql在为了并发量和数据隔离方面做了很多的尝试,其中MVCC就是比较好的解决方案。

也就是面试最常见的4大隔离级别。

       1.读未提交          其它事务未提交就可以读
       2.读已提交          其它事务只有提交了才能读
       3.可重复读          只管自己启动事务时候的状态,不受其它事务的影响(mysql默认)
       4.事务串行          按照顺序提交事务保证了数据的安全性,但无法实现并发

一致性:

即数据一致性,是通过上面的三种加起来联合实现的。

ACID只是个概念,最终目的就是保证数据的一致性和可靠不丢。

 

Undo Log

所谓的undo log就是回滚日志,当进行插入、删除、修改操作时,一定会生成undo log,并且一定优先于修改后的数据落盘

我直接借用别人的图了,zhangsan的银行账户有1000元,他要转400元到理财账户。

可以看到,每一条变更数据的操作,都伴随一条undo log的生成。undo log就是记录数据的原始状态。这一点在一些其他的分布式事务的框架里也有所使用,譬如seata就是采用自己解析sql并生成反向sql存储下来,将来抛异常时就执行回滚语句的方式来做的分布式事务,而不借助于mysql自身的undo log机制。

有了undo log,如果事务执行失败要回滚,那很简单,直接将undo log里的回滚语句执行一遍就好了。mysql就是通过这种方式完成的原子性。

Redo Log

redo log是完成数据持久性的,事务一旦提交,其所做的修改就会永久保存到数据库中,而不能丢失,即便是mysql服务器挂掉了也不能丢。

mysql数据是存储到磁盘的,但读写其实都是操作的buffer pool缓存(前面几篇讲过insert buffer)。这样就会造成写入时,如果仅仅写入到buffer pool了,还没来得及刷入数据页,那么mysql突然宕机,就会丢失数据。

此时redo log的作用就出来了,在写入buffer pool后会同时写入到redo log(顺序写磁盘)一份,redo log有固定的大小,会被重复使用。

MVCC及隔离级别

mvcc是什么

MVCC (MultiVersion Concurrency Control) 叫做多版本并发控制。理解为:事务对数据库的任何修改的提交都不会直接覆盖之前的数据,而是产生一个新的版本与老版本共存,使得读取时可以完全不加锁。

有点抽象是吗,再来详细解释一下。同一行数据会有多个版本,某事务对该数据的修改并不会直接覆盖老版本,而是产生一个新版本和老版共存。然后在该行追加两个虚拟的列,列就是进行数据操作的事务的ID(created_by_txn_id),是一个单调递增的ID;还有一个deleted_by_txn_id,将来用来做删除的。

那么在另一个事务在读取该行数据时,由具体的隔离级别来控制到底读取该行的哪个版本。同时,在读取过程中完全不加锁,除非用select * xxx for update强行加锁。

譬如read committed级别,每次读取,总是取事务ID最大的那个就好了。

对于Repeatable read,每次读取时,总是取事务ID小于等于当前事务的ID的那些数据记录。在这个范围内,如果某一数据有多个版本,则取最新的。

MVCC在mysql中的实现依赖的是undo log与read view

undo log记录某行数据的多个版本的数据;read view用来判断当前版本数据的可见性。

mysql就是用MVCC来实现读写分离不加锁的。

那么MVCC里多出来的那些版本的数据最终是要删除的,支持MVCC的数据库套路一般差不多,都会有一个后台线程来定时清理那些肯定没用的数据。只要一个数据的deleted_by_txn_id不为空,并且比当前还没结束的事务ID最小的一个还小,该数据就可以被清理掉了。在PostgreSQL中,该清理任务叫“vacuum”,在Innodb中,叫做“purge”。

 

隔离级别

隔离级别目的很明确,管理多个并发读写请求的访问顺序,包括串行和并行,要在并发性能和读取数据的正确性上做个权衡

其中的两个隔离级别Serializable和 Read Uncommited几乎用不上,这里不谈。

Read Committed

能读到其他事务已提交的内容,这是Springboot默认的隔离级别。一个事务在他提交之前的所有修改,对其他事务不可见。提交后,其他事务就能读到了。在很多场景下这种逻辑是可以接受的。

在这个隔离级别下,读取数据不加锁而是使用MVCC机制,写入数据就是排他锁。该级别会产生不可重复读和幻读问题。

不可重复读就是在一个事务内多次读取的结果不一样,这个很容易理解,上面讲MVCC时也说了,该级别每次select时都会去读取最新的版本,所以同一个事务内,也就是代码前面一行select了,后面又select了,可能会select到不同的值。因为这两次select过程中,有其他事务对select的行进行了事务提交,就会被select出来最新的。

幻读,即一个事务能够读取到插入的新数据。会出现幻读也是一样的道理,第一次select时还没值,再次select时又有值了。

Repeatable Read

这个级别名字就是可重复读,这是mysql默认的隔离级别。

为什么能重复读,前面讲MVCC时也说了,这个级别下,一旦读到某个版本,后续都是这个版本了,好比是一次快照,就不关心其他事务对该行数据的提交了,它只认第一次读取时的版本号。

这个级别在一些场景下很重要,如

     数据备份:
             例如数据库S从数据库M中复制数据,但是M又不停的在修改数据。S需要拿到M的一个数据快照,但又不能停M。
     数据合法性校验:
             例如有两张表,一张记录了当时的交易总额,另一张记录了每个交易的金额。那么在读取数据时,如果没有快照的存在,交易总额就可能和当时的交易总额对不上。

该级别依然会出现幻读的问题,repeatable是可以出现幻读的,一个事务虽然不能读取其他事务对现有数据的修改,但是能够读取到插入的新数据。

即便是MVCC也解决不了幻读的问题,这里有一篇讲的原因。

写前提困境

尽管在MVCC的加持下Read Committed和Repeatable Read都可以得到很好的实现。但是对于某些业务代码来讲,在当前事务中看到/看不到其他的事务已经提交的修改的意义不是很大。这种业务代码一般是这样的:

    先读取一段现有的数据

    在这个数据的基础上做逻辑判断或者计算;

    将计算的结果写回数据库。

这样第三步的写入就会依赖第一步的读取。但是在1和3之间,不管业务代码离得有多近,都无法避免其他事务的并发修改。换句话说,步骤1的数据正确是步骤3能够在业务上正确的前提,这样其实与MVCC都没什么关系了,因为我们想象中的要操作的数据和实际值并不一样,无论怎么步骤3的结果其实都不对了。

无论你用哪种隔离,你都无法解决第一步读取的数据和第三步操作之间,别的事务对它的修改。

解决方法:

结论

虽然上面写了很多,也很复杂,貌似不上锁怎么都难以解决写前提困境。而事实上,我们几乎不用考虑这样的场景,极少有可能说多个客户端同时操作同一条数据,又刚好碰上需要抉择read committed还是Repeatable read的困境。

结论很简单,不管他就好,你几乎没机会碰到这样的选择困境。

这篇关于mysql事务(包括redo log,undo log,MVCC)及事务实现原理的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/854530

相关文章

SQL中的外键约束

外键约束用于表示两张表中的指标连接关系。外键约束的作用主要有以下三点: 1.确保子表中的某个字段(外键)只能引用父表中的有效记录2.主表中的列被删除时,子表中的关联列也会被删除3.主表中的列更新时,子表中的关联元素也会被更新 子表中的元素指向主表 以下是一个外键约束的实例展示

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

如何去写一手好SQL

MySQL性能 最大数据量 抛开数据量和并发数,谈性能都是耍流氓。MySQL没有限制单表最大记录数,它取决于操作系统对文件大小的限制。 《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB,才推荐分库分表。性能由综合因素决定,抛开业务复杂度,影响程度依次是硬件配置、MySQL配置、数据表设计、索引优化。500万这个值仅供参考,并非铁律。 博主曾经操作过超过4亿行数据

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

MySQL数据库宕机,启动不起来,教你一招搞定!

作者介绍:老苏,10余年DBA工作运维经验,擅长Oracle、MySQL、PG、Mongodb数据库运维(如安装迁移,性能优化、故障应急处理等)公众号:老苏畅谈运维欢迎关注本人公众号,更多精彩与您分享。 MySQL数据库宕机,数据页损坏问题,启动不起来,该如何排查和解决,本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志,排查哪个表(表空间

【C++】_list常用方法解析及模拟实现

相信自己的力量,只要对自己始终保持信心,尽自己最大努力去完成任何事,就算事情最终结果是失败了,努力了也不留遗憾。💓💓💓 目录   ✨说在前面 🍋知识点一:什么是list? •🌰1.list的定义 •🌰2.list的基本特性 •🌰3.常用接口介绍 🍋知识点二:list常用接口 •🌰1.默认成员函数 🔥构造函数(⭐) 🔥析构函数 •🌰2.list对象

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全栈,前后端开发,小程序开发,人工智能,js逆向,App逆向,网络系统安全,数据分析,Django,fastapi

hdu4407(容斥原理)

题意:给一串数字1,2,......n,两个操作:1、修改第k个数字,2、查询区间[l,r]中与n互质的数之和。 解题思路:咱一看,像线段树,但是如果用线段树做,那么每个区间一定要记录所有的素因子,这样会超内存。然后我就做不来了。后来看了题解,原来是用容斥原理来做的。还记得这道题目吗?求区间[1,r]中与p互质的数的个数,如果不会的话就先去做那题吧。现在这题是求区间[l,r]中与n互质的数的和