MySQL对事务的支持

1.01^1000

已于 2024-08-17 17:49:07 修改

阅读量642

点赞数 9

分类专栏： [000-01].我的后端学习大纲 [000-02].我的数据库学习大纲文章标签： mysql

于 2024-08-17 17:22:05 首次发布

本文链接：https://blog.csdn.net/weixin_43783284/article/details/141283827

版权

[000-01].我的后端学习大纲同时被 2 个专栏收录

180 篇文章 0 订阅

订阅专栏

[000-02].我的数据库学习大纲

11 篇文章 0 订阅

订阅专栏

5.MySQL对事务的支持情况：

5.1. 查看存储引擎对事务的支持情况：

1.SHOW ENGINES 命令来查看当前 MySQL 支持的存储引擎都有哪些，以及这些存储引擎是否支持事务
2.下图可以能看出在 MySQL 中，只有InnoDB类型的存储引擎是支持事务的

5.2.MySQL支持的四种隔离级别

不同的数据库厂商对SQL标准中规定的四种隔离级别支持不一样。比如,Oracle就只支持READ COMNITTED（默认隔离级别〉和SERIALIZABLE隔离级别

MySQL虽然支持4种隔离级别，但与SQL标准中所规定的各级隔离级别允许发生的问题却有些出入，MySQL在REPEATABLE READ隔离级别下，是可以禁止幻读问题的发生的，禁

a.MySQL的默认隔离级别:

1.MySQL的默认隔离级别为REPEATABLE READ，我们可以手动修改一下事务的隔离级别
2.查看mysql的默认隔离级别，这个命令与mysql的版本有关系：

# 查看隔离级别，MySQL 5.7.20的版本之前：
SHOW VARIABLES LIKE 'tx_isolation';
/*
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tx_isolation | REPEATABLE-READ  |
+---------------+-----------------+
*/
# MySQL 5.7.20版本之后，引入transaction_isolation来替换tx_isolation
# 查看隔离级别，MySQL 5.7.20的版本及之后：
SHOW VARIABLES LIKE 'transaction_isolation';
/*
+-----------------------+-----------------+
| Variable_name         | Value           |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+
*/
#或者不同MySQL版本中都可以使用的：
SELECT @@transaction_isolation;
/*
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| REPEATABLE-READ         |
+-------------------------+
*/

5.3.,MySQL中如何设置事务的隔离级别

a.更改隔离级别的语句：

在这里插入图片描述

b.关于`设置时使用GLOBAL或SESSION`的影响：

1.使用 GLOBAL 关键字（在全局范围影响）：
- 对当前已经存在的会话无效：当前会话是sessionA ，那对A无效，仅仅对SessionB,SessionC这样的新会话有效果
- 只对执行完该语句之后产生的会话起作用
```
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE; 
#或
SET GLOBAL TRANSACTION_ISOLATION = 'SERIALIZABLE';
```
2.使用 SESSION 关键字（在会话范围影响）：
- 对当前会话的所有后续的事务有效
- 如果在事务之间执行，则对后续的事务有效
- 该语句可以在已经开启的事务中间执行，但不会影响当前正在执行的事务
```
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE; 
#或
SET SESSION TRANSACTION_ISOLATION = 'SERIALIZABLE';
```

小结：数据库规定了多种事务隔离级别，不同隔离级别对应不同的干扰程度，隔离级别越高，数据一致性就越好，但并发性越弱

3.6.GLOBAL和Session的演示

a.GLOBAL演示：

1.先看会话1：设置隔离级别
2.在去会话2：查看新的隔离级别
3.3.再回到会话1：重启会话1后，发现是新的隔离级别

b.SESSION 演示：

1.会话1：设置隔离级别并查看
2.会话2：

3.7.不同隔离级别举例:

a.数据准备：

1.创建数据表并且导入数据：

b. 演示1：READ UNCOMMITTED``读未提交之脏读

1.设置隔离级别为未提交读：
2.事务1和事务2的执行流程如下：

c.演示2:读已提交:`READ COMMITTED`：

在这里插入图片描述

d.演示3：可重复读``REPEATABLE READ

1.举例1：可以解决脏读，可重复度的问题
2.举例2：这种情况会有幻读的情况：
1.这里要灵活的理解读取的意思。第一次select是读取，第二次的insert其实也属于隐式的读取，只不过是在mysql的机制中读取的，插入数据也是要先读取一下有没有主键冲突才能决定是否执行插入
2.幻读，并不是说两次读取获取的结果集不同，幻读侧重的方面是某一次的select 操作得到的结果所表征的数据状态无法支撑后续的业务操作。更为具体一些: select某记录是否存在，不存在，准备插入此记录，但执行insert时发现此记录已存在，无法插入，此时就发生了幻读。
3.在RR隔离级别下，step1、step2是会正常执行的，step3则会报错主键冲突，对于事务1的业务来说是执行失败的，这里事务1就是发生了幻读，因为事务1在step1中读取的数据状态并不能支撑后续的业务操作，事务1:“见鬼了，我刚才读到的结果应该可以支持我这样操作才对啊，为什么现在不可以"。事务1不敢相信的又执行了step4，发现和setp1读取的结果是一样的（RR下的 MVCC机制)。此时，幻读无疑已经发生，事务1无论读取多少次，都查不到id=3的记录，但它的确无法插入这条他通过读取来认定不存在的记录（此数据已被事务2插入)，对于事务1来说，它幻读了。
4.其实RR（Mysql默认隔离级别）也是可以避免幻读的，通过对select操作手动加行X锁(独占锁) (SELECT … FOR UPDATE这也正是SERIALIZABLE 隔离级别下会隐式为你做的事情)，同时，即便当前记录不存在，比如id = 3是不存在的，当前事务也会获得一把记录锁（因为InnoDB的行锁锁定的是索引，故记录实体存在与否没关系，存在就加行X锁，不存在就加间隙领），其他事务则无法插入此索引的记录，故杜绝了幻读。
5.在SERIALIZABLE隔离级别下，step1执行时是会隐式的添加行(X)锁/gap(X)锁的，从而step2会被阻塞，step3 会正常执行，待事务1提交后，事务2才能继续执行（主键冲突执行失败)，对于事务1来说业务是正确的，成功的阻塞扼杀了扰乱业务的事务2，对于事务1来说他前期读取的结果是可以支撑其后续业务的。
6.所以MySQL的幻读并非什么读取两次返回结果集不同，而是事务在插入事先检测不存在的记录时，惊奇的发现这些数据已经存在了，之前的检测读获取到的数据如同鬼影一般