RR隔离级别下还有幻读吗

于 2024-09-03 20:36:17 发布
阅读量609 收藏 16
点赞数 16
文章标签： mysql 幻读 隔离级别
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhuanzhuantech/article/details/141871069
版权

文章目录

1 背景

InnoDB默认的事务隔离级别是REPEATABLE-READ，它为了解决该隔离级别并发情况下的幻读问题，使用了LBCC（基于锁的并发控制）和MVCC（多版本的并发控制）两种方案。其中LBCC解决的是当前读情况下的幻读问题，MVCC解决的是快照读情况下的幻读问题，那既然如此，该隔离级别下是否仍然还存在幻读的问题呢？幻读问题到底有没有完全解决呢？基于这样的疑问，下面我们来进行验证下吧。

2 验证

2.1 验证准备

2.1.1 环境信息
MySQL版本：5.6.36
存储引擎：InnoDB
隔离级别：REPEATABLE-READ
2.1.2 数据准备

为了进行验证，在测试库建立了一张测试使用的用户信息表，并且插入了3条初始数据。

CREATE TABLE `user_info` (
	`id` BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键id',
	`name` VARCHAR ( 32 ) NOT NULL DEFAULT '' COMMENT '姓名',
	`gender` VARCHAR ( 32 ) NOT NULL DEFAULT '' COMMENT '性别',
	`email` VARCHAR ( 32 ) NOT NULL DEFAULT '' COMMENT '邮箱',
PRIMARY KEY ( `id` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8mb4 COMMENT = '用户信息表';

INSERT INTO `user_info` (`id`, `name`, `gender`, `email`) VALUES (1, 'Curry', '男', 'curry@163.com');
INSERT INTO `user_info` (`id`, `name`, `gender`, `email`) VALUES (2, 'Wade', '男', 'wade@163.com');
INSERT INTO `user_info` (`id`, `name`, `gender`, `email`) VALUES (3, 'James', '男', 'james@163.com');
commit;

2.2 当前读场景验证

首先我们先来看看当前读的场景下会不会出现幻读的问题。

2.2.1 前言
  • 什么是当前读

当前读（Locking Read）也称为锁定读，读取的是数据当前的最新版本，而且读取到这个数据之后会对这个数据加锁，防止别的事务进行更改，即通过next-key锁（唯一索引next-key锁会退化为记录锁）来解决当前读中的脏读，幻读，不可重复读问题，也就是LBCC的方式。在进行写操作的时候也需要进行“当前读”，读取数据记录的最新版本。当前读包含以下SQL类型：select … lock in share mode 、select … for update、update 、delete 、insert。

  • 什么是临键锁

我们将数据库中存储的每一行数据称为记录。如上图中1、5、9、12分别代表id为当前数的记录。对于键值在条件范围内但不存在的记录，叫做间隙（GAP）。则上图中的（-∞，1）、（1，5）…（12，+∞）为数据库中存在的间隙。而（-∞，1]、（1，5]…（12，+∞）我们称之为临键，即左开右闭的集合。当我们对上面的记录和间隙共同加锁时，添加的便是临键锁。

2.2.2 场景验证

触发当前读的方式有很多种，这里仅使用select lock in share mode这种方式来进行当前读幻读问题验证。

  • 场景：
  1. 开启事务1
  2. 在事务1中通过select lock in share mode进行当前读查询用户信息
  3. 开启事务2
  4. 在事务2中插入一条新数据
  5. 提交事务2
  6. 在事务1中再次查询用户信息
  7. 提交事务1
mysql> START TRANSACTION; -- 1.开启事务1
Query OK, 0 rows affected (0.00 sec)
mysql> select * from user_info lock in share mode; -- 2.读锁方式查询用户信息
+----+-------+--------+---------------+
| id | name  | gender | email         |
+----+-------+--------+---------------+
|  1 | Curry | 男     | curry@163.com |
|  2 | Wade  | 男     | wade@163.com  |
|  3 | James | 男     | james@163.com |
+----+-------+--------+---------------+
3 rows in set (0.00 sec)

mysql> START TRANSACTION; -- 3.开启事务2
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO `user_info` (`id`, `name`, `gender`, `email`) VALUES (4, 'White', '男', 'white@163.com'); -- 4.在事务2中插入一条新数据

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction  -- 因锁等待插入未成功，最终等待超时，事务回滚终止
  • 场景验证结果

可以看到在事务1中开始事务执行了当前读后，事务2在进行插入新数据时进入了锁等待，最后发生了锁等待超时，导致事务终止回滚。插入数据因锁的原因是不会成功的，因此事务1第二次查询时也不会查询到新记录，所以此场景下不会产生幻读的问题。

2.2.3 小结

由场景验证结果可以看到，由于临键锁的存在，会阻塞其他事务对加锁间隙的数据插入，所以当前读场景下通过LBCC是可以完全解决幻读的问题。

2.3.快照读场景验证

那接下来我们再看看快照读场景下是怎么样的。

2.3.1 前言
  • 什么是快照读

由于当前读是通过LBCC基于锁的方式来进行并发控制，是悲观锁的实现，同时也会因为锁的原因，造成锁冲突的概率变大，也会导致性能的下降，因此基于提高并发性能的考虑，引入了快照读，快照读顾名思义即读取的是数据的快照版本，快照读的实现是基于MVCC多版本并发控制，它在很多情况下，避免了加锁操作，降低了性能开销。

2.3.2 场景验证
  • 场景一
  1. 开启事务1
  2. 在事务1中查询用户信息
  3. 开启事务2
  4. 在事务2中插入一条新数据
  5. 提交事务2
  6. 在事务1中再次查询用户信息
  7. 提交事务1
mysql> START TRANSACTION; -- 1.开启事务1
Query OK, 0 rows affected (0.00 sec)
mysql> select * from user_info; -- 2.在事务1中查询用户信息
+----+-------+--------+---------------+
| id | name  | gender | email         |
+----+-------+--------+---------------+
|  1 | Curry | 男     | curry@163.com |
|  2 | Wade  | 男     | wade@163.com  |
|  3 | James | 男     | james@163.com |
+----+-------+--------+---------------+
3 rows in set (0.00 sec)
mysql> select * from user_info; 6.在事务1中再次查询用户信息
+----+-------+--------+---------------+
| id | name  | gender | email         |
+----+-------+--------+---------------+
|  1 | Curry | 男     | curry@163.com |
|  2 | Wade  | 男     | wade@163.com  |
|  3 | James | 男     | james@163.com |
+----+-------+--------+---------------+
3 rows in set (0.00 sec)
mysql> commit; -- 7.提交事务1
Query OK, 0 rows affected (0.00 sec)

mysql> START TRANSACTION; -- 3.开启事务2
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO `user_info` (`id`, `name`, `gender`, `email`) VALUES (4, 'White', '男', 'white@163.com'); -- 4.在事务2中插入一条新数据
Query OK, 1 row affected (0.00 sec)

mysql> commit; -- 5.提交事务2
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user_info;
+----+-------+--------+---------------+
| id | name  | gender | email         |
+----+-------+--------+---------------+
|  1 | Curry | 男     | curry@163.com |
|  2 | Wade  | 男     | wade@163.com  |
|  3 | James | 男     | james@163.com |
|  4 | White | 男     | white@163.com |
+----+-------+--------+---------------+
4 rows in set (0.00 sec)
  • 场景验证结果

从场景一来看RR级别下是可以避免幻读的问题，在意料之中。
那如果我们在事务1中两次查询之间进行了当前读更新操作呢，那会不会出现幻读的问题呢，那接下来我们来看一看场景二。

  • 场景二
  1. 开启事务1
  2. 在事务1中查询用户信息
  3. 开启事务2
  4. 在事务2中插入一条新数据
  5. 提交事务2
  6. 在事务1中将ID为1的数据的用户姓名修改为Iversen
  7. 在事务1中再次查询用户信息
  8. 提交事务1
mysql> START TRANSACTION; -- 1. 开启事务1
Query OK, 0 rows affected (0.00 sec)
mysql> select * from user_info; -- 2. 在事务1中查询用户信息
+----+-------+--------+---------------+
| id | name  | gender | email         |
+----+-------+--------+---------------+
|  1 | Curry | 男     | curry@163.com |
|  2 | Wade  | 男     | wade@163.com  |
|  3 | James | 男     | james@163.com |
+----+-------+--------+---------------+
3 rows in set (0.00 sec)
mysql> update user_info set name = 'Iversen' where id = 1; -- 在事务1中将ID为1的数据的用户姓名修改为Iversen
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
mysql> select * from user_info; -- 7. 在事务1中再次查询用户信息
+----+---------+--------+---------------+
| id | name    | gender | email         |
+----+---------+--------+---------------+
|  1 | Iversen | 男     | curry@163.com |
|  2 | Wade    | 男     | wade@163.com  |
|  3 | James   | 男     | james@163.com |
+----+---------+--------+---------------+
3 rows in set (0.00 sec)
mysql> commit; -- 8. 提交事务1
Query OK, 0 rows affected (0.00 sec)

mysql> START TRANSACTION; -- 3.开启事务2
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO `user_info` (`id`, `name`, `gender`, `email`) VALUES (4, 'White', '男', 'white@163.com'); -- 4.在事务2中插入一条新数据
Query OK, 1 row affected (0.00 sec)

mysql> commit; -- 5.提交事务2
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user_info;
+----+-------+--------+---------------+
| id | name  | gender | email         |
+----+-------+--------+---------------+
|  1 | Curry | 男     | curry@163.com |
|  2 | Wade  | 男     | wade@163.com  |
|  3 | James | 男     | james@163.com |
|  4 | White | 男     | white@163.com |
+----+-------+--------+---------------+
4 rows in set (0.00 sec)
  • 场景验证结果

从场景二来看RR级别下仍然是可以避免幻读的问题，那是不是就可以确定RR级别下已经完全解决了幻读的问题呢。那我们再换一种更新方式来看看吧。

  • 场景三
  1. 开启事务1
  2. 在事务1中查询用户信息
  3. 开启事务2
  4. 在事务2中插入一条新数据
  5. 提交事务2
  6. 在事务1中将所有用户的邮箱信息的后缀更换为@gmail.com
  7. 在事务1中再次查询用户信息
  8. 提交事务1
mysql> START TRANSACTION; -- 1. 开启事务1
Query OK, 0 rows affected (0.00 sec)
mysql> select * from user_info; -- 2. 在事务1中查询用户信息
+----+-------+--------+---------------+
| id | name  | gender | email         |
+----+-------+--------+---------------+
|  1 | Curry | 男     | curry@163.com |
|  2 | Wade  | 男     | wade@163.com  |
|  3 | James | 男     | james@163.com |
+----+-------+--------+---------------+
3 rows in set (0.00 sec)
mysql> update user_info set email = REPLACE(email, '@163.com', '@gmail.com'); -- 6. 在事务1中将所有用户的邮箱信息的后缀更换为@gmail.com
Query OK, 4 rows affected (0.00 sec)
Rows matched: 4  Changed: 4  Warnings: 0
mysql> select * from user_info;  -- 7. 在事务1中再次查询用户信息
+----+-------+--------+-----------------+
| id | name  | gender | email           |
+----+-------+--------+-------------- --+
|  1 | Curry | 男     | curry@gmail.com |
|  2 | Wade  | 男     | wade@gmail.com  |
|  3 | James | 男     | james@gmail.com |
|  4 | White | 男     | white@gmail.com |
+----+-------+--------+-----------------+
4 rows in set (0.00 sec)
mysql> commit;  -- 8. 提交事务1
Query OK, 0 rows affected (0.00 sec)

mysql> START TRANSACTION; -- 3.开启事务2
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO `user_info` (`id`, `name`, `gender`, `email`) VALUES (4, 'White', '男', 'white@163.com'); -- 4.在事务2中插入一条新数据
Query OK, 1 row affected (0.00 sec)

mysql> commit; -- 5.提交事务2
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user_info;
+----+-------+--------+---------------+
| id | name  | gender | email         |
+----+-------+--------+---------------+
|  1 | Curry | 男     | curry@163.com |
|  2 | Wade  | 男     | wade@163.com  |
|  3 | James | 男     | james@163.com |
|  4 | White | 男     | white@163.com |
+----+-------+--------+---------------+
4 rows in set (0.00 sec)
  • 场景验证结果

事务1在进行更新之后再次查询读取到了事务2新插入到数据，出现了幻读。

2.3.3 小结

看来RR级别的确没有完全解决幻读问题，那为什么还会存在幻读的问题呢，为什么更新的方式不同，会出现不同的结果，什么情况下还会出现幻读问题呢。带着这样的疑问，我们来探索下～

3 分析

从验证结果来看，当前读是可以完全避免幻读的问题，而对于快照读如果在两次读取之间进行了当前读，在某些情况下是会触发幻读的问题。那么下面我们可以从当前读的实现(MVCC)的角度来分析幻读问题的产生原因。

我们应该知道MVCC实现原理主要是依赖记录中的3个隐式字段，undo日志，Read View来实现的，好，那么我们基于产生幻读的场景结合MVCC的实现原理来一步步进行分析。

1.产生幻读的场景

  1. 初始三条测试数据
  2. 开启事务1
  3. 在事务1中查询用户信息
  4. 开启事务2
  5. 在事务2中插入一条新数据
  6. 提交事务2
  7. 在事务1中将所有用户的邮箱信息更换为@gmail.com
  8. 在事务1中再次查询用户信息
  9. 提交事务1

1.1 执行步骤0：初始三条测试数据

在初始化三条数据后三条初始数据分别会有三个隐式字段值，

DB_TRX_ID(事务id),DB_ROLL_PTR(回滚指针),DB_ROW_ID(隐式主键)。

如下：因为是新插入的数据,回滚指针字段的值均为NULL。

+----+-------+--------+--------------+-----------+-----------+---------+
| id | name  | gender | email        | DB_TRX_ID |DB_ROLL_PTR|DB_ROW_ID|
+----+-------+--------+--------------+-----------+-----------+---------+
|  1 | Curry | 男     | curry@163.com|    2334   |    NULL   |    1    |
|  2 | Wade  | 男     | wade@163.com |    2334   |    NULL   |    2    |
|  3 | James | 男     | james@163.com|    2334   |    NULL   |    3    |
+----+-------+--------+--------------+-----------+-----------+---------+

1.2 执行步骤1：开启事务1

在开启事务1后会为事务1分配一个唯一的事务id

mysql> SELECT trx_id,trx_state,trx_started  FROM INFORMATION_SCHEMA.INNODB_TRX;
+-----------------+-----------+---------------------+
| trx_id          | trx_state | trx_started         |
+-----------------+-----------+---------------------+
| 2335            | RUNNING   | 2024-07-28 21:31:52 |
+-----------------+-----------+---------------------+
1 row in set (0.00 sec)

1.3 执行步骤2：在事务1中查询用户信息

因为是开启事务后的首次查询，所以此时会生成一张Read Veaw读视图，此时trx_list，up_limit_id，low_limit_id的值分别为：

trx_list：因为是测试验证，无其他并发事务参与，所以活跃事务列表中只有当前的事务id[2335];

up_limit_id：活跃事务列表中最小的事务id，即当前事务id:2335;

low_limit_id：下一个未开始的事务id,即当前事务id+1为:2336;

此时查询数据会使用当前生成的Read View并依据可见性算法来进行查询，因为数据库中数据的事务id均小于up_limit_id所以对当前事务均是可见的，所以三条初始数据会全部被查询出来。

注: 可见性算法

  1. 首先比较 DB_TRX_ID < up_limit_id , 如果小于，则当前事务能看到 DB_TRX_ID 所在的记录，如果大于等于进入下一个判断
  2. 接下来判断 DB_TRX_ID >= low_limit_id , 如果大于等于则代表 DB_TRX_ID 所在的记录在 Read View 生成后才出现的，那对当前事务肯定不可见，如果小于则进入下一个判断
  3. 判断 DB_TRX_ID 是否在活跃事务之中，trx_list.contains (DB_TRX_ID)，如果在，则代表Read View 生成时刻，这个事务仍处于活跃中，还没有commit，如果DB_TRX_ID=creator_trx_id，则说明是当前事务自己产生的数据，是可见的，如果不等于，则为其他事务修改的数据，当前事务也是看不见的；如果不在活跃事务之中，则说明，你这个事务在Read View生成之前就已经commit了，修改的结果，当前事务是能够看见的。

1.4 执行步骤3：开启事务2

在开启事务2后会为事务2分配一个唯一的事务id。

事务id的分配是递增的，因此事务2的事务id一定是大于事务1。

mysql> SELECT trx_id,trx_state,trx_started  FROM INFORMATION_SCHEMA.INNODB_TRX;
+-----------------+-----------+---------------------+
| trx_id          | trx_state | trx_started         |
+-----------------+-----------+---------------------+
| 2336            | RUNNING   | 2024-07-28 21:35:52 |
+-----------------+-----------+---------------------+
1 row in set (0.00 sec)

1.5 执行步骤4：在事务2中插入一条新数据

此时会产生一条新插入数据的insert undolog日志

1.6 执行步骤5：提交事务2

由于事务提交插入的数据会实际生效，insert undolog日志会被删除,此时表的数据情况如下：

+----+-------+--------+--------------+-----------+-----------+---------+
| id | name  | gender | email        | DB_TRX_ID |DB_ROLL_PTR|DB_ROW_ID|
+----+-------+--------+--------------+-----------+-----------+---------+
|  1 | Curry | 男     | curry@163.com|    2334   |    NULL   |    1    |
|  2 | Wade  | 男     | wade@163.com |    2334   |    NULL   |    2    |
|  3 | James | 男     | james@163.com|    2334   |    NULL   |    3    |
|  4 | White | 男     | white@163.com|    2336   |    NULL   |    4    |
+----+-------+--------+--------------+-----------+-----------+---------+

1.7 执行步骤6：在事务1中将所有用户的邮箱信息的后缀更换为@gmail.com

因为是更新操作，所以是当前读会将所有的符合条件的数据都读取出来，进行更新。
更新后的数据表中的数据如下：

+----+-------+--------+----------------+-----------+-----------+---------+
| id | name  | gender | email         | DB_TRX_ID |DB_ROLL_PTR|DB_ROW_ID|
+----+-------+--------+----------------+-----------+-----------+---------+
|  1 | Curry | 男     |curry@gmail.com |    2335   |  0x123825 |    1    |
|  2 | Wade  | 男     |wade@gmail.com  |    2335   |  0x153125 |    2    |
|  3 | James | 男     |james@gmail.com |    2335   |  0x115725 |    3    |
|  4 | White | 男     |white@gmail.com |    2335   |  0x163225 |    4    |
+----+-------+--------+----------------+-----------+-----------+---------+

undolog情况如下：

1.8 执行步骤7：在事务1中再次查询用户信息

  • 当前是RR的隔离级别，所以此时使用的Read View读视图仍然是首次查询生成的读视图。

  • 依据Read View的可见性算法分析，分别对四条数据的undolog版本链从尾部至头部逐一进行可见性判断是否可见进行追溯，会看到四条数据的尾部版本就可对当前事务可见。所以四条数据是会在此次查询中全部被查询得到。

由此可以推断产生幻读的原因啦，因为事务1中的更新操作，对事务2中的新插入的数据也进行了更新，更新后新数据的undolog日志中会追加此次更新的回滚日志，并指向新插入数据的undolog记录，此时根据MVCC的可见性算法，事务2新插入的数据此时对于事务1也变成了可见的，因此产生了幻读的问题。

  • 那同样是更新场景二为什么没有产生幻读的问题呢？

在场景二中，更新语句更新的是事务1第一次查询可见的数据，而对事务2中新插入的数据没有进行任何操作，新插入数据的版本链中是不存在当前事务产生的版本数据的，因此新插入的数据对与事务1仍然不可见，所以没有产生幻读问题。

4 总结

  1. 当前读可以通过锁机制完全避免幻读问题，快照读如果中间对其他事务已提交的插入或更新的数据进行了更新，则会出现幻读的问题。
  2. 如何进行避免呢？
  • 采用串行化的隔离级别（不建议）；
  • 开发时注意考虑这种产生幻读的场景，尽量通过调整代码逻辑规避幻读问题的发生（建议）；
  • 若不能通过调整代码逻辑规避，可以考虑采用当前读的方式避免（建议）；

关于作者 孔德志 采货侠JAVA开发工程师

转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~

转转技术团队
关注
  • 16
    点赞
  • 踩
  • 16
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
InnoDB在RR隔离级别下的幻读问题的分析
Legolas_PRC的博客
02-07 396
对innDB在RR隔离级别下幻读问题的简单分析
MySQL RR隔离级别解决幻读问题？
dadaoke的专栏
01-27 1631
首先，讲mysql的隔离级别之前需要复习一下事务的四个特性 （注：mysql存储引擎InnoDB）（待完善） 事务的四个特性（ACID）： 原子性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持久性（Durability） 数据库允许多个并发事务同时对其数据进行读写和修改的能力，可能出现的问题有： 脏读 不可重复读 幻读 隔离性有不同的级别 事务隔离级别 读未提交（read uncommitted） 读提交（read committed） 可重复读（rep
mysql的innodb RR隔离级别能解决幻读吗
chang765721的博客
07-20 2414
解决脏读、不可重复读以及幻读问题
mysql rr解决幻读吗_mysql rr隔离级别解决幻读了吗
weixin_31437175的博客
01-18 2572
以下内容全部基于innodb。虽然下面有很多概念很浅显，但还是要解释一下什么是幻读？当一个事务在多次查询中，发现了一行不是在当前事务中添加的数据。出现这种问题就叫做幻读。关于四种隔离级别未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据提交读(Read Committed)：只能读取到已经提交的数据。解决了脏读，未解决不可重复读问题。可重复读(R...
可重复读（RR）隔离级别下，幻读被彻底解决了吗？
weixin_44866921的博客
07-18 351
之后事务 B 向表中新插入了一条 id = 5 的记录并提交（事务A不可见）。接着，事务 A 对 id = 5 这条记录进行了更新操作，在这个时刻，这条新记录的 trx_id 隐藏列的值就变成了事务 A 的事务 id，之后事务 A 再使用普通 select 语句去查询这条记录时就可以看到这条记录了，于是就发生了幻读。T1 时刻：事务 A 先执行「快照读语句」：select * from t_test where id > 100 得到了 3 条记录。就会得到 4 条记录，此时也发生了幻读现象。
MySQL 在RR隔离级别下会产生幻读吗？
fuwei2020的博客
01-28 1094
事务A进行一次查询，之后事务B插入一条数据，事务A进行第二次查询，如果两次查询到的数量不同，就是发生了幻读。举个例子，假设有一张表user，表中有字段age，没有索引。事务A事务B1beginbegin234commit56commit如果2和5两次查出的条数不等，则说明发生了幻读。
InnoDB如何在RR隔离级别下实现避免幻读的？
方圆 Blog
05-08 685
我是方圆，让我们一起来提高 1. InnoDB如何在RR隔离级别下实现避免幻读的？ InnoDB引擎，RR隔离级别下，并不能完全组织幻读的发生，想避免幻读，要保证gap锁是开启的，也就是innodb_locks_unsafe_for_binlog参数值为off（默认情况是off） 表象：快照读通过MMVC（基于事务版本控制的协议）和undo日志实现的。 在这里要区分一下快照读和当前读...
MySQL InnoDB RR隔离级别是否能够避免幻读？
wtopps的专栏
04-09 757
背景 在MySQL的InnoDB引擎中，支持四种事务隔离级别，分别如下： 1、READ UNCOMMITED（未提交读）：使用查询语句不会加锁，允许脏读，也就是可能读取到其他会话中未提交事务修改的数据。 2、READ COMMITED（提交读）：只能读取到已经提交的数据，只对记录加记录锁，而不会在记录之间加间隙锁，所以允许新的记录插入到被锁定记录的附近，所以再多次使用查询语句时，可能得到不同的结果（Non-Repeatable Read）。 3、REPEATABLE READ（可重复读）：多次读取同一范围的
InnoDB 在可重复读 RR 隔离级别下，能解决幻读问题吗？
一切随缘的博客
05-27 1184
InnoDB 在可重复读 RR 隔离级别下，能解决幻读问题吗？MySQL 在「可重复读」隔离级别下，可以很大程度上避免幻读现象的发生（注意是很大程度避免，并不是彻底避免），所以 MySQL 并不会使用「串行化」隔离级别来避免幻读现象的发生，因为使用「串行化」隔离级别会影响性能。解决方案有两种：● 针对快照读(普通的select语句)，是通过MVCC的方式解决了幻读问题。
隔离级别RR、间隙锁、幻读
sinat_14913533的博客
03-07 749
在每个讲mysql的资料中，应该都会讲到事务的这4个特性：ACID。而这4个特性又会着重讲的就是隔离性，因为在mysql的实现中在并发度和隔离性上作了权衡和取舍，分为了4个隔离级别。在不同的隔离级别会支持一定的并发度，但是也会存在右并发带来的一些问题。隔离级别从低到高：RU-->RC-->RR-->Serializable，隔离级别越高，并发度越低，并发问题也就越少。 如下就是...
MySQL事务隔离级别中可重复读与幻读
2301_79099460的博客
04-19 992
在说幻读之前,我们要先来了解脏读和不可重复读。
MySQL可重复读隔离级别能解决幻读吗？
ht1301584915的博客
11-05 2745
事务及事务隔离级别 innodb存储引擎支持事务，myisam不支持事务 事务内的操作要么全部成功，要么全部失败，中途有失败则回滚 事务的ACID：原子性，一致性，隔离性，持久性 事务隔离级别需要解决的问题： 脏读：读到其他事务未提交的事务 不可重复读：同一事务内，不同时刻读到的同一批数据可能不一样 幻读：对于插入来说的，事务A按照一定条件进行数据读取，期间事务B插入了相同搜索条件的新数据，事务A再次按照原先条件进行读取时，发现事务B新插入的数据 事
Mysql可重复读隔离级别下如何解决幻读
dycy的博客
11-17 3204
Mysql可重复读隔离级别下如何解决幻读一些概念具体加锁说明使用主键索引进行等值查询使用主键索引进行范围查询使用二级索引进行等值查询使用二级索引进行范围查询 一些概念 幻读：在一次事务中，同一条select语句在先后两次查询中得到了不同的记录。 MySql可重复读隔离级别下解决了幻读。 快照读的幻读用MVCC解决，当前读的幻读用间隙锁解决 MVCC，快照读和当前读的概念：MVCC及实现原理 下面只分析当前读的幻读。 一些锁的概念： 共享锁（Shared）：又称S锁，读锁，共享锁，加了S锁其他事务可以读，不
面试被反问，RR级别下能解决幻读问题那为什么不叫幻读级别？
weixin_42907817的博客
07-04 6207
字节后台一面凉经放这，有需要自己去看哈 字节跳动飞书后台工程师一面，应该是个凉经 Q：你讲讲innodb的锁机制吧 A：blablablabla介绍了行锁表锁意向锁，读锁写锁 Q：还有呢 A：介绍了四种锁算法，record lock, gap lock, next-key lock, previous-key lock，最后我提了一嘴，innodb在rr隔离级别下是通过next-key算法来避免幻读问题的。（先别骂，第一次面试紧张死了，确实有问题） Q：在rr级别下能解决幻读问题那为什么不叫幻读级别呢，你做
MySQL——事务与存储过程（一）事务管理（3）事务的回滚
PAP
08-30 796
MySQL——事务与存储过程（一）事务管理（3）事务的回滚
mysql-day02
m0_64370841的博客
08-29 2265
【代码】mysql-day02。
MySQL 函数、约束、多表查询与事务详解
A_cot的博客
08-30 1726
在 MySQL 数据库中，函数、约束、多表查询和事务是非常重要的概念，它们可以帮助我们更好地管理和操作数据。本文将详细介绍这些概念，并通过代码演示来帮助你更好地理解。
如何在 MySQL 中使用 Socket 身份验证 ？
xiaochong0302的博客
08-31 1444
在 MySQL 和 MariaDB 中，可以使用 socket 身份验证，而不是传统的用户名和密码组合。这种方法既安全又方便，因为它使用的是操作系统的用户凭证。
【MySQL】索引使用规则——（覆盖索引，单列索引，联合索引，前缀索引，SQL提示，数据分布影响，查询失效情况）
最新发布
YYDsis的博客
08-31 1301
一.索引使用规则 ※.验证索引效率提升 1.覆盖索引——查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到2.单列索引＆联合索引3.前缀索引——解决冗长字符串与索引问题【1】前缀索引＆索引选择性的介绍【2】前缀索引创建演示：5.SQL提示——指定某个索引/忽略索引/强制索引 6.数据分布影响——MySQL自我评估7.查询失效的几种情况【1】违背——最左前缀法则(联合索引)【2】范围查询右侧失效【3】用or分割开的条件，or后面没索引，所有索引失效【4】索引列上进行运算操作，索引
RR与RC隔离级别下索引与锁测试脚本实例与详解
测试脚本将包括一系列针对不同隔离级别的操作，如读取、更新和删除，以便观察在RR和RC隔离级别下，索引和锁如何工作，以及如何避免可能出现的问题，如幻读和死锁。 通过学习和实践这些脚本，开发者可以更好地理解...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值