MySQL---事务
🔎定义
事务的本质是将多条 SQL 语句打包成一个整体
要么全部成功, 要么全部不执行
而不会出现执行一半这种特殊情况
举个栗子🌰
sql
# 如果存在 account, 删除
mysql> drop table if exists account;
# 创建 account
mysql> 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 语句
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
sql
# 开启事务
start transaction
# 执行相关业务代码
# ...
# 提交事务
commit🔎事务的特性
事务有4个关键特性, 也就是常说的 ACID
- 原子性(Atomicity)
- 一致性(Consistency)
- 隔离性(Isolation)
- 持久性(Durability)
原子性
原子性是事务最核心的特性
上述所说事务本质中将多条 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---事务的隔离级别
- READ UNCOMMITTED → 读未提交
- READ COMMITTED → 读已提交
- REPEATABLE READ → 可重复读(MySQL 默认的事务隔离级别)
- SERIALIZABLE → 串行化
| 事务隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| 读未提交(READ UNCOMMITTED) | ✔ | ✔ | ✔ |
| 读已提交(READ COMMITTED) | ✘ | ✔ | ✔ |
| 可重复读(REPEATABLE READ) | ✘ | ✘ | ✔ |
| 串行化(SERIALIZABLE) | ✘ | ✘ | ✘ |
- 读未提交 → 没有任何锁限制, 并发程度最高(执行效率最高), 隔离性最低(数据准确性最低)
- 读已提交 → 给读操作加锁
- 可重复读 → 给读操作加锁 + 给写操作加锁
- 串行化 → 并发程度最低(执行效率最低), 隔离性最高(数据准确性最高)
注意
事务的隔离级别没有好坏, 只有最适合的场景
涉及到转账操作, 数据准确性 > 执行效率
涉及到点赞操作, 执行效率 > 数据准确性
🌸🌸🌸完结撒花🌸🌸🌸
