【MySQL】事务

本文详细阐述了MySQL事务的ACID特性,包括原子性、一致性、隔离性和持久性。讨论了并发事务带来的问题以及MySQL的隔离级别如何解决这些问题,特别介绍了undolog和redolog的区别,以及MVCC在事务隔离机制中的作用。
摘要由CSDN通过智能技术生成

【MySQL】事务

1. 事务的特性(ACID)是什么?能详细说一下吗?

事务是一组操作的集合,它是一个不可分割的工作单位,事务会把所有的操作作为一个整体一起向系统提交或者撤销请求,即这些操作要么同时成功,要么同时失败。

在这里插入图片描述

回答:

  • ACID,分别指的是:原子性、一致性、隔离性、持久性;我举个例子:A 向 B 转账 500,转账成功,A 扣除 500 元,B 增加 500 元,原子操作体现在要么都成功,要么都失败;
  • 在转账的过程中,数据要一致,A 扣除了 500,B 必须增加 500;
  • 在转账的过程中,隔离性体现在 A 向 B 转账 500 不会因为收到别人向 A / B 转账等事务的干扰;
  • 在转账的过程中,持久性体现在事务提交后,要把数据进行持久化,即落盘操作(数据落入磁盘),用户查余额能看到变化。

补充:单条 sql 是原子的,多条 sql 则需要事务来保证原子性;

2. 并发事务带来什么问题?怎么解决这些问题?MySQL 的默认隔离级别是什么?

  • 并发事务问题:【丢失更新、脏读】、不可重复读、幻读
  • 解决方案就是 MySQL 的隔离级别:读未提交、读已提交、可重复读、串行化

在这里插入图片描述

在这里插入图片描述


在这里插入图片描述


幻读:

  • 读到的内容不变,但是”范围可能不同“,例如事物①第一次查不到 id 为 1,但是事务②提交了个 id 为 1的一行,事务①再次查 id 为 1 的数据就多了一条了。(范围由 0 到 1)

在这里插入图片描述

解决方案:对事务进行隔离

在这里插入图片描述

幻读:

对于这种”范围“相关的查询,数据行的整个的新增与丢失,是不能用行级锁来避免的,但是表级锁会限制整个表的并发访问,可能会造成性能瓶颈,并且会增加系统的锁竞争,降低系统的并发能力,影响很多服务。

MySQL 的事务隔离机制则只会用到粒度小的行级锁。所以串行化来处理显然好一些,但是由于其会导致所有操作串行执行,性能开销较大;对于一些可能出现幻读的场景,并且影响严重再使用串行化(此事务不与其他事务并行,而是串行)

回答:

并发事务的问题:

  • 丢失修改,脏读、不可重复读、幻读;
  • 丢失修改就是一个事务的修改覆盖了另一个事务的修改;
  • 脏读就是一个事务读到了另一个事务还没提交的数据;
  • 不可重复读就是一个事务先后读取同一条记录时,单词两次读取的数据不同;
  • 幻读就是一个事务按条件查询数据时,没有对应的数据 ,但别的事务增加对应的数据行后,又发现这行数据行存在;

隔离级别:

  • READ UNCOMMITTED 未提交读,都未解决;
  • READ COMMITTED 读已提交,解决:丢失修改、脏读;
  • PEPEATABLE READ 可重复读,解决:丢失修改、脏读、不可重复读;
  • SERIALIZABLE 串行化:解决:丢失修改、脏读、不可重复读、幻读;

3. undo log 与 redo log 的区别

在这里插入图片描述

在这里插入图片描述

3.1 undo log

在这里插入图片描述

命令 → undo log buffer(缓存) → 逆命令记录到 undo log file → 回滚事务

3.2 redo log

在这里插入图片描述

在这里插入图片描述

命令 → redo log buffer(缓存) → redo log file(磁盘固定位置) → 刷新脏数据/重做

  • 事务提交的持久化就是通过这个 redo log 实现的!
  • 固定的两个位置有 redo log file,提高性能,避免选择随机的磁盘位置
  • 并且 InnoDB 要求 redo log file,文件至少有 2 个,初始文件为 ib_logfile0 和 ib_logfile1, ib_logfile0 写完以后写 ib_logfile1,等到 ib_logfile1 也写完了,从头又开始写 ib_logfile0,这样就形成了一个环形写入的结构。但是覆盖写入的前提是要确定哪个位置点是可以覆盖写的,哪些位置是不能覆盖写的,这个就是 check point 的工作了。
    • 一个文件不也是环形写入吗?
    • 是这样的,但是会提高遇到不能覆盖写的点的概率,影响性能!

3.3 回答

  • redo log:记录的是数据页的物理变化,服务宕机可用来同步数据,保证了事务的持久性
  • undo log:记录的则是逻辑日志,即“增删改操作”的逆操作命令,当事务回滚时,通过逆操作回复原来的数据,服务宕机时可用来撤销数据,保证了事务的原子性一致性

4. 事务的隔离机制是如何保证的呢?(解释一下 MVCC)

  1. :排他锁(如果一个事务获取了一个数据行的排他锁,其他事务就不能再获取该行的锁)
  2. MVCC:多版本并发控制,通过一些算法,不用锁来提高获取的记录正确的概率(很高);

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

快照读与当前读,可以参考文章:

当前读就是有利用锁机制的,而快照读则利用 MVCC;

在这里插入图片描述

A

在这里插入图片描述

回答:

  • 隐藏字段:
    1. trx_id(事务 id),记录每一次操作的事务 id,是自增的;
    2. roll_pointer(回滚指针),指向了上一个本的事务记录地址;
  • undo log:
    1. 回滚日志,存储增删改的逆命令;
    2. 版本链:多个事务并行操作某一行之类,记录不同事务修改数据的版本(一次提交一个版本),通过 roll_pointer 指针形成一个链表;
  • readView 解决的是一个事务查询选择版本的问题:
    1. 根据 readView 的匹配规则 和当前的一些事务 id 判断访问哪个版本的数据;
    2. 不同的隔离级别快照读是不一样的,最终访问的结果不一样:
      • RC(读已提交):每一次执行快照读生成 ReadView;
      • RR(可重复读):仅在事务中第一次执行快照读时生成 ReadView,后续复用这个 ReadView;
  • 18
    点赞
  • 29
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

s:103

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值