文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

MySQL—事务

2023-08-16 14:18

关注

🔎定义


事务的本质是将多条 SQL 语句打包成一个整体
要么全部成功, 要么全部不执行
而不会出现执行一半这种特殊情况

举个栗子🌰

# 如果存在 account, 删除mysql> drop table if exists account;# 创建 accountmysql> create table account(    -> id int,    -> balance decimal(10,1)    -> );# 插入数据mysql> insert into account(id, balance)    -> values(1, 1000), (2, 0);# 查询结果mysql> select * from account;+------+---------+| id   | balance |+------+---------+|    1 |  1000.0 ||    2 |     0.0 |+------+---------+

针对上述情况, 当用户1向用户2转账时执行如下 SQL 语句

update account set balance = balance - 500 where id = 1;update account set balance = balance + 500 where id = 2;

事务就是确保上述的 SQL 语句要么全部成功, 要么全部不执行

此处所说的全部不执行不是真的不执行
而是执行了, 但执行过程中发现执行出错, 从而进行回滚(恢复数据)
即将数据恢复为最初的模样

在 MySQL5.7 中
开启事务 → start transaction
提交事务 → commit

# 开启事务start transaction# 执行相关业务代码# ...# 提交事务commit

🔎事务的特性


事务有4个关键特性, 也就是常说的 ACID

原子性


原子性是事务最核心的特性

上述所说事务本质中将多条 SQL 语句打包成一个整体即为原子性

一致性


一致性是指事务执行前后的数据要保持一致

举个栗子🌰

A 给 B 转账500
转账成功后 A 账户余额 - 500, B 账户余额 + 500(数据保持一致)
转账成功后 A 账户余额 - 500, B 账户余额 + 5000(数据未保持一致)

持久性


事务修改的内容是写到硬盘上持久存在的
即使重启也不会丢失

隔离性


隔离性是为了解决并发执行事务时引起的问题

对于并发的解释🌰

餐馆(服务器)接待顾客(客户端)就餐

顾客较少时, 可能出现的点餐情况是一个接一个的点餐

就餐高峰时, 可能出现的点餐情况是许多顾客同时点餐
(服务器同时处理多个客户端的请求称为并发)

如果并发执行事务时, 修改的是不同的表 / 不同的数据, 一般不会有问题
如果并发执行事务时, 修改的是相同的表 / 相同的数据, 可能会带来问题

而事务的隔离性就是为了解决数据库并发处理事务时可能出现的问题

🔎并发执行事务可能产生的问题


并发执行事务可能产生的问题包括

脏读


举个栗子🌰

A 同学正在写代码, B 同学经过 A 同学身边看到了 A 写的代码, 然后就走了
很可能 B 同学走之后 A 同学的代码因为其他原因又进行了一些修改
B 同学第二天上课时候发现 A 同学的代码变了

一个事务 T1 正在对数据进行修改时, 还没进行最终的定稿
另一个事务 T2 对该数据进行了读取, 此时 T2 读取到的数据称为"脏数据"

脏数据指代的不是数据被灰尘弄脏了, 而是说数据的内容是无效的 → 即 A 同学又把代码进行了修改

针对上述这个栗子如果不理解, 可以自行带入考试时有的同学抄邻座同学的答案
出于一些原因, 邻座的同学故意将错答案写在卷子上等到其他同学抄完再故意改正

解决脏读问题🍂

为了解决脏读问题, MySQL 引入了给写操作加锁
即 A 同学修改代码时 B 同学不能读(读, 写操作不再能并发执行)

通过给写操作加锁, 降低了并发程度(降低了效率), 提高了隔离性(提高了数据准确性)

不可重复读


举个栗子🌰

A 同学写代码, 此时 B 同学再次从 A 同学身边路过
但由于之前约定的 A 同学修改代码时 B 同学不能看(给写操作加锁)
于是 A, B 商定等到 A 同学提交代码之后再通过 A 的 Gitee 链接进行观看
A 同学提交代码, B 同学进行观看, 此时 A 同学修改其他的代码, 于是 B 看着看着发现 A 的代码发生了变化

这就是不可重复读问题

事务 T1 提交了数据, 此时事务 T2 尝试读取数据
在读取过程中, 事务 T3 又提交了数据
此时的效果是事务 T2 读取的数据前后不一致 → 即不可重复读问题
(预期结果是同一个事物多次读取的结果相同)

解决不可重复读问题🍂

同学 B 发现读取的内容发生变化, 于是和 A 商定读取时 A 不能修改数据(给读加锁操作)

通过给读加锁操作, 进一步降低了事务的并发处理能力(降低了效率), 提高了事务的隔离性(提高了数据的准确性)

幻读


当前已经约定了给写操作加锁(解决脏读问题), 给读操作加锁(解决不可重复读问题)

由于约定 B 同学读取数据时 A 同学不能修改代码, 于是 A 同学觉得很无聊
此时 A 同学想, 既然你不让我修改你读取的代码, 那我修改其他的代码总可以了吧
于是 A 同学就对代码中其他的部分进行了修改
在 B 同学读取结束后发现 A 同学的其他部分代码中新添加了一些内容

这就是幻读问题

在给写操作加锁, 给读操作加锁前提下
事务 T1 两次读取同一个数据, 发现读取数据的内容是相同的, 但是数据的结果集是不同的 → 即幻读问题

解决幻读问题🍂

数据库使用串行化的方式解决幻读问题, 即彻底放弃并行处理事务, 一个接一个的串行处理事务

通过串行化的方式, 事务的并发处理能力最低(执行效率最低), 事务的隔离性最高(数据的准确性最高)

即 B 同学读取数据时, A 同学远离任何能修改代码的机会(串行化)

总结


🔎MySQL—事务的隔离级别


  1. READ UNCOMMITTED → 读未提交
  2. READ COMMITTED → 读已提交
  3. REPEATABLE READ → 可重复读(MySQL 默认的事务隔离级别)
  4. SERIALIZABLE → 串行化
事务隔离级别脏读不可重复读幻读
读未提交(READ UNCOMMITTED)
读已提交(READ COMMITTED)
可重复读(REPEATABLE READ)
串行化(SERIALIZABLE)

注意

事务的隔离级别没有好坏, 只有最适合的场景

涉及到转账操作, 数据准确性 > 执行效率
涉及到点赞操作, 执行效率 > 数据准确性

🌸🌸🌸完结撒花🌸🌸🌸

在这里插入图片描述

来源地址:https://blog.csdn.net/m0_74365243/article/details/131865612

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-数据库
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯