全部栏目

首页 行业资讯 美食菜系 特产小吃 健康饮食 教你做菜
您的当前位置：首页MySQL--REPEATABLE-READ隔离级别下读取到的“重复数据”

MySQL--REPEATABLE-READ隔离级别下读取到的“重复数据”

2023-11-12 来源：六九路网
table tb002;create table tb002(id int primary key,c2 int,unique index uni_c2(c2));begin;insert into tb002(id,c2) select 1,1;insert into tb002(id,c2) select 2,2;insert into tb002(id,c2) select 4,4;commit;

假设有回话A和回话B,均使用REPEATABLE-READ隔离级别

##========================================================##

首先回话A执行SQL：

begin;select * from tb002;

返回结果如下：

技术分享

##========================================================##

然后回话B执行SQL：

begin;delete from tb002 where id=2;commit;

由于回话A没有加锁，所以回话B能顺利完成删除并提交事务，当前数据库中无C2=2的记录，且会话B提交事务释放锁。

##========================================================##

回到回话A执行SQL：

insert into tb002(id,c2) select 3,2;

由于当前数据库中无C2=2的记录，且其他回话没有在此C2=2的范围上加锁，因此回话A可以完成C2=2的数据插入。

在回话A上再次进行查询：

select * from tb002;

返回结果如：

技术分享

C2上有唯一索引，但为什么查询结果中仍包含两条C2=2的记录呢？ID=2的记录属于快照读的数据，ID=3的记录数据当前读的数据，MySQL将当前读和快照读的数据进行简单的合并后返回给客户端，并不检查“结果数据是否满足唯一索引”的要求。

##========================================================##

上面的测试针对唯一索引进行，那如果针对主键会有啥区别呢？

将插入SQL修改为：

insert into tb002(id,c2) select 2,3;

即回话B删除的ID值和回话A新插入的ID值相同情况下，最后的查询结果并不会包含两条相同ID的记录，对于“快照读”和“当前读”两个结果集存在"主键冲突“的情况，最终返回客户端的结果会”丢弃“快照读中的”老版本“记录，保留最新版本的记录。

可见对于主键不存在上述问题。

##========================================================##

总结：

在基于MVCC实现的REPEATABLE-READ隔离级别下，由于快照读和当前读的影响，会导致返回数据结果集超过”期望结果集“的情况，甚至返回结果集中包含重复的”唯一索引键“，但返回结果集中不会包含重复的“主键”（PS：单表查询的前提下）。

如果在事务中包含先插入后查询的情况，应该考虑上述问题对业务的影响。

##========================================================##

技术分享

 

MySQL--REPEATABLE-READ隔离级别下读取到的“重复数据”

标签：并且   合并   期望   执行   mvcc   read   返回结果   logs   释放   

小编还为您整理了以下内容，可能对您也有帮助：

mysql事务隔离级别

mysql事务隔离级别如下：

1.读取未提交（READ-UNCOMMITTED）：最低的隔离级别，允许读取尚未提交的数据变更，可能造成脏读、不可重复读、幻读。

2.读取已提交（READ-COMMITTED）：允许读取并发事务已经提交的数据，可以避免脏读，但是可能造成不可重复、幻读。

3.可重复读（REPEATABLE-READ）：对同一字段多次读取的结果都是一致的，除非本身事务修改，可以避免脏读和不可重复读，但是可能造成幻读。

4.可串行化（SERIALIZABLE）：最高的隔离级别，完全服从ACID的隔离级别，所以的事务依次执行，可以避免脏读、不可重复读、幻读。

事务的特性：

1.原子性：事务最小的执行单位，不允许分割。事务的原子性确保动作要么全部执行，要么全部不执行。

2.一致性：执行事务的前后，数据保持一致。例如转账的业务中，无论事务是否成功，转账者和收款人的总额应该是不变的。

3.隔离性：并发访问数据库时，一个用户的事务不应该被其他事务所影响，各并发事务之间数据库是独立的。

4.持久性：一个事务被提交后，它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有影响。

mysql事务隔离级别

mysql事务隔离级别如下：

1.读取未提交（READ-UNCOMMITTED）：最低的隔离级别，允许读取尚未提交的数据变更，可能造成脏读、不可重复读、幻读。

2.读取已提交（READ-COMMITTED）：允许读取并发事务已经提交的数据，可以避免脏读，但是可能造成不可重复、幻读。

3.可重复读（REPEATABLE-READ）：对同一字段多次读取的结果都是一致的，除非本身事务修改，可以避免脏读和不可重复读，但是可能造成幻读。

4.可串行化（SERIALIZABLE）：最高的隔离级别，完全服从ACID的隔离级别，所以的事务依次执行，可以避免脏读、不可重复读、幻读。

事务的特性：

1.原子性：事务最小的执行单位，不允许分割。事务的原子性确保动作要么全部执行，要么全部不执行。

2.一致性：执行事务的前后，数据保持一致。例如转账的业务中，无论事务是否成功，转账者和收款人的总额应该是不变的。

3.隔离性：并发访问数据库时，一个用户的事务不应该被其他事务所影响，各并发事务之间数据库是独立的。

4.持久性：一个事务被提交后，它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有影响。

MySQL的默认事务隔离级别是?

mysql的4种事务隔离级别，如下所示：

1、未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据。

2、提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)。

3、可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读，但是innoDB解决了幻读。

4、串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞。

相关简介

MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。

MySQL是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。

MySQL所使用的 SQL 语言是用于访问数据库的最常用标准化语言。MySQL 软件采用了双授权*，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择 MySQL 作为网站数据库。

MySQL的默认事务隔离级别是?

mysql的4种事务隔离级别，如下所示：

1、未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据。

2、提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)。

3、可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读，但是innoDB解决了幻读。

4、串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞。

相关简介

MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。

MySQL是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。

MySQL所使用的 SQL 语言是用于访问数据库的最常用标准化语言。MySQL 软件采用了双授权*，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择 MySQL 作为网站数据库。

MySQLInnoDB四个事务级别与脏读、不重复读、幻读是什么

1、MySQL InnoDB事务隔离级别脏读、可重复读、幻读MySQL InnoDB事务的隔离级别有四级，默认是“可重复读”（REPEATABLE READ）。

· 1）.未提交读（READUNCOMMITTED）。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据（脏读）( 隔离级别最低，并发性能高 )。

· 2）.提交读（READCOMMITTED）。本事务读取到的是最新的数据（其他事务提交后的）。问题是，在同一个事务里，前后两次相同的SELECT会读到不同的结果（不重复读）。会出现不可重复读、幻读问题（锁定正在读取的行）

· 3）.可重复读（REPEATABLEREAD）。在同一个事务里，SELECT的结果是事务开始时时间点的状态，因此，同样的SELECT操作读到的结果会是一致的。但是，会有幻读现象（稍后解释）。会出幻读（锁定所读取的所有行）。

· 4）.串行化（SERIALIZABLE）。读操作会隐式获取共享锁，可以保证不同事务间的互斥（锁表）。

‘

四个级别逐渐增强，每个级别解决一个问题。

· 1）.脏读。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据。

· 2）.不重复读。解决了脏读后，会遇到，同一个事务执行过程中，另外一个事务提交了新数据，因此本事务先后两次读到的数据结果会不一致。

· 3）.幻读。解决了不重复读，保证了同一个事务里，查询的结果都是事务开始时的状态（一致性）。但是，如果另一个事务同时提交了新数据，本事务再更新时，就会“惊奇的”发现了这些新数据，貌似之前读到的数据是“鬼影”一样的幻觉。

具体地：

1). 脏读

首先区分脏页和脏数据

脏页是内存的缓冲池中已经修改的page，未及时flush到硬盘，但已经写到redo log中。读取和修改缓冲池的page很正常，可以提高效率，flush即可同步。脏数据是指事务对缓冲池中的行记录record进行了修改，但是还没提交！！！，如果这时读取缓冲池中未提交的行数据就叫脏读，违反了事务的隔离性。脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。

2). 不可重复读

是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，第二个事务已经提交。那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。如果只有在作者全部完成编写后编辑人员才可以读取文档，则可以避免该问题

3). 幻读 :

是指当事务不是执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。例如，一个编辑人员更改作者提交的文档，但当生产部门将其更改内容合并到该文档的主复本时，发现作者已将未编辑的新材料添加到该文档中。如果在编辑人员和生产部门完成对原始文档的处理之前，任何人都不能将新材料添加到文档中，则可以避免该问题。

2、隔离级别实验 以下实验基于博主MySQL Server 5.6

首先创建一个表，如下：

USE test;

CREATE TABLE `t` (

`a` int(11) NOT NULL PRIMARY KEY

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

2.1、实验一：解释脏读、可重复读问题

事务A READ-UNCOMMITTED

事务B READ-COMMITTED,

事务C-1 REPEATABLE-READ

事务C-2 REPEATABLE-READ

事务D SERIALIZABLE

set autocommit =0;

start transaction ;

start transaction;

insert into t(a)values(4);

select * from t;

1,2,3,4(脏读：读取到了未提交的事务中的数据)

select * from t;

1,2,3（解决脏读）

select * from t;

1,2,3

select * from t;

1,2,3

select * from t;

1,2,3

commit;

select * from t:

1,2,3,4

select * from t:

1,2,3,4

select * from t:

1,2,3,4 (与上面的不在一个事务中，所以读到为事务提交后最新的，所以可读到4)

select * from t:

1,2,3（重复读：由于与上面的在一个事务中，所以只读到事务开始事务的数据，也就是重复读）

select * from t:

1,2,3,4

commit（提交事务，下面的就是一个新的事务，所以可以读到事务提交以后的最新数据）

select * from t:

1,2,3,4

READ-UNCOMMITTED 会产生脏读，基本很少适用于实际场景，所以基本不使用。

2.2、实验二：测试READ-COMMITTED与REPEATABLE-READ事务A

事务B READ-COMMITTED

事务C REPEATABLE-READ

set autocommit =0;

start transaction ;

start transaction;

start transaction;

insert into t(a)values(4);

select * from t;

1,2,3

select * from t;

1,2,3

commit;

select * from t:

1,2,3,4

select * from t:

1,2,3（重复读：由于与上面的在一个事务中，所以只读到事务开始事务的数据，也就是重复读）

commit（提交事务，下面的就是一个新的事务，所以可以读到事务提交以后的最新数据）

select * from t:

1,2,3,4

REPEATABLE-READ可以确保一个事务中读取的数据是可重复的，也就是相同的读取（第一次读取以后，即使其他事务已经提交新的数据，同一个事务中再次select也并不会被读取）。

READ-COMMITTED只是确保读取最新事务已经提交的数据。

当然数据的可见性都是对不同事务来说的，同一个事务，都是可以读到此事务中最新数据的。如下，

start transaction;

insert into t(a)values(4);

select *from t;

1,2,3,4;

insert into t(a)values(5);

select *from t;

1,2,3,4,5;

2.3、实验三：测试SERIALIZABLE事务对其他的影响

事务A SERIALIZABLE事务B READ-UNCOMMITTED

事务C READ-COMMITTED,

事务D REPEATABLE-READ

事务E SERIALIZABLE

set autocommit =0;

start transaction ;

start transaction;

select a from t union all select sleep(1000) from al;

insert into t(a)values(5);

insert into t(a)values(5);

insert into t(a)values(5);

insert into t(a)values(5);

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

SERIALIZABLE 串行化执行，导致所有其他事务不得不等待事务A结束才行可以执行，这里特意使用了sleep函数，直接导致事务B,C,D,E等待事务A持有释放的锁。由于我sleep了1000秒，而innodb_lock_wait_timeout为120s。所以120s到了就报错HY000错误。

SERIALIZABLE是相当严格的串行化执行模式，不管是读还是写，都会影响其他读取相同的表的事务。是严格的表级读写排他锁。也就失去了innodb引擎的优点。实际应用很少。

2.4、实验四：幻读一些文章写到InnoDB的可重复读避免了“幻读”（phantom read），这个说法并不准确。做个实验：(以下所有试验要注意存储引擎和隔离级别)

CREATE TABLE `t_bitfly` (

`id` bigint(20) NOT NULL default '0',

`value` varchar(32) default NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

select @@global.tx_isolation, @@tx_isolation;

+-----------------------+-----------------+

| @@global.tx_isolation | @@tx_isolation |

+-----------------------+-----------------+

| REPEATABLE-READ | REPEATABLE-READ |

+-----------------------+-----------------+

实验4-1：

Session ASession B

start transaction ;start transaction ;SELECT * FROM t_bitfly;

empty set

INSERT INTO t_bitfly VALUES (1, 'a');COMMIT;SELECT * FROM t_bitfly;

| empty set

INSERT INTO t_bitfly VALUES (1, 'a');

|ERROR 1062 (23000):

|Duplicate entry '1' for key 1

(刚刚明明告诉我没有这条记录的)I如此就出现了幻读，以为表里没有数据，其实数据已经存在了，提交后，才发现数据冲突了。

实验4-2：

Session A

Session B

start transaction ;

start transaction ;

SELECT * FROM t_bitfly;

| +------+-------+

| | id | value |

| +------+-------+

| | 1 |a |

| +------+-------+

INSERT INTO t_bitfly VALUES (2, 'b');

SELECT * FROM t_bitfly;

| +------+-------+

| | id | value |

| +------+-------+

| | 1 |a |

| +------+-------+

COMMIT;

SELECT * FROM t_bitfly;

| +------+-------+

| | id | value |

| +------+-------+

| | 1 |a |

| +------+-------+

UPDATE t_bitfly SET value='z';

| Rows matched: 2 Changed:2 Warnings: 0

(怎么多出来一行)

SELECT * FROM t_bitfly;

| +------+-------+

| | id | value |

| +------+-------+

| | 1 |z |

| | 2 |z |

| +------+-------+

本事务中第一次读取出一行，做了一次更新后，另一个事务里提交的数据就出现了。也可以看做是一种幻读。

附说明

那么，InnoDB指出的可以避免幻读是怎么回事呢？

http://dev.mysql.com/doc/refman/5.0/en/innodb-record-level-locks.html

By default, InnoDB operatesin REPEATABLE READ transaction isolation level and with the innodb_locks_unsafe_for_binlog system variable disabled. In this case, InnoDB uses next-key locks for searches and index scans, which prevents phantom rows (see Section 13.6.8.5,

“Avoidingthe Phantom Problem Using Next-Key Locking”).

准备的理解是，当隔离级别是可重复读，且禁用innodb_locks_unsafe_for_binlog的情况下，在搜索和扫描index的时候使用的next-keylocks可以避免幻读。

关键点在于，是InnoDB默认对一个普通的查询也会加next-key locks，还是说需要应用自己来加锁呢？如果单看这一句，可能会以为InnoDB对普通的查询也加了锁，如果是，那和序列化（SERIALIZABLE）的区别又在哪里呢？

MySQL manual里还有一段：

13.2.8.5. Avoiding the PhantomProblem Using Next-Key Locking (http://dev.mysql.com/doc/refman/5.0/en/innodb-next-key-locking.html)

Toprevent phantoms, InnoDB usesan algorithm called next-key

locking that combinesindex-row locking with gap locking.

Youcan use next-key locking to implement a uniqueness check in your application:If you read your data in share mode and do not see a plicate for a row you are going to insert, then you can safely insert your row and know that the next-key lock set on the

success or of your row ring the read prevents anyone mean while inserting a plicate for your row. Thus, the next-key locking enables you to “lock” the nonexistence of something in your table.

我的理解是说，InnoDB提供了next-key locks，但需要应用程序自己去加锁。manual里提供一个例子：

SELECT * FROM child WHERE id> 100 FOR UPDATE;

这样，InnoDB会给id大于100的行（假如child表里有一行id为102），以及100-102，102+的gap都加上锁。

可以使用show engine innodb status来查看是否给表加上了锁。

再看一个实验，要注意，表t_bitfly里的id为主键字段。

实验4-3：

Session A

Session B

start transaction ;

start transaction ;

SELECT * FROM t_bitfly

WHERE id<=1

FOR UPDATE;

| +------+-------+

| | id | value |

| +------+-------+

| | 1 |a |

| +------+-------+

INSERT INTO t_bitfly VALUES (2, 'b');

| Query OK, 1 row affected

SELECT * FROM t_bitfly;

| +------+-------+

| | id | value |

| +------+-------+

| | 1 |a |

| +------+-------+

INSERT INTO t_bitfly VALUES (0, '0');

| (waiting for lock ...

| then timeout) ERROR 1205 (HY000):Lock wait timeout exceeded;

|try restarting transaction

SELECT * FROM t_bitfly;

| +------+-------+

| | id | value |

| +------+-------+

| | 1 |a |

| +------+-------+

COMMIT;

SELECT * FROM t_bitfly;

| +------+-------+

| | id | value |

| +------+-------+

| | 1 |a |

| +------+-------+

可以看到，用id<=1加的锁，只锁住了id<=1的范围，可以成功添加id为2的记录，添加id为0的记录时就会等待锁的释放。

附说明：

MySQL manual里对可重复读里的锁的详细解释：

http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html#isolevel_repeatable-read

For locking reads (SELECT with FOR

UPDATE or LOCK IN SHARE MODE),UPDATE,

and DELETE statements, locking depends on whether the statement uses

a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition, InnoDB locks

only the index record found, not the gap before it. For other search conditions, InnoDB locks

the index range scanned, using gap locks or next-key (gap plus index-record)locks to block insertions by other sessions into the gaps covered by the range.

一致性读和提交读，先看实验，

实验4-4：

Session A

Session B

start transaction ;

start transaction ;

SELECT * FROM t_bitfly;

| +------+-------+

| | id | value |

| +------+-------+

| | 1 |a |

| +------+-------+

INSERT INTO t_bitfly VALUES (2, 'b');

COMMIT;

SELECT * FROM t_bitfly;

| +------+-------+

| | id | value |

| +------+-------+

| | 1 |a |

| +------+-------+

SELECT * FROM t_bitfly LOCK IN SHARE MODE;

| +----+-------+

| | id | value |

| +----+-------+

| | 1 |a |

| | 2 |b |

| +----+----

1.3 REPEATABLE READ（可重复读）

1.设置为可重复读

SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;

2.首先TB做出一次查询，此时name为bb

3.TA对数据进行修改，并提交

4.此时加入session C作为对比，使用自动事务并做出查询，可见数据已经被修改

5.在已经开启事务的TB中，查询到的，仍然是数据开启事务之前的状态，所以数据是可重复读的

可重复读隔离级别中，每当事务开始后，第一次执行sql语句时（或者执行START TRANSACTION WITH CONSISTENT SNAPSHOT）MVCC会建立一个read view，选取当时的系统版本号，作为事务版本号，以Undo log的行系统版本号与事务版本号进行对比，增删改查都要遵循如下模式：

SELECT：

1, InnoDB只查找版本早于当前事务版本的数据行(行的系统版本号小于等于事务版本号)，这样可以确保事务读取的行，要么是事务开始前就存在的，要么是事务自身插入的或修改过的。

2, 行的删除号要么未定义，要么大于当前事务版本号，这样可以确保事务读取到的行，在事务开始之前未被删除。

INSERT：

InnoDB 为新插入的每一行保存当前系统版本号做为行版本号。

DELETE：

INNODB 为删除的每一行保存当前系统版本号作为行删除标识。

UPDATE：

InnoDB 为插入的每一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。

所以READ COMMITTED和REPEATABLE READ的区别在于，READ COMMITTED总是读取被锁定行的最新一份快照数据， 所以会有不可重复读的问题。而REPEATABLE READ读取事务开始时行系统版本号小于事务版本号的数据，解决不可重复读的问题。

此外要提的一点是，MySql的REPEATABLE READ与Oracle的不同，不但解决了不可重复读问题，还解决的“幻读”问题。

幻读的产生：遵循上述增删改查模式，假设TA事务的事物版本号为3，TB早于TA开启事务，TB事物版本号为2，TB先新增一条数据，行数据的版本号为2，并提交。TB提交后，TA查询时，满足“行的系统版本号小于等于事务版本号”的条件，可以查到数据，形成“幻读”。

InnoDB采用Next-key Lock(间隙锁)来避免“幻读”问题。

Record Lock：单个行记录的锁，锁定的是索引而非记录本身。

GAP Lock：间隙锁，锁定一个范围，但不包含记录本身。

Next-Key Lock：Gap Lock+Record Lock 锁定一个范围并锁定记录本身。

举例说明：

某表字段为ID和NAME，有3条睡觉，ID分别为10，20，50。

如果索引为 10，20，50，那么：

Record Lock：select * from tab where id = 10 for update; //对id=10单行进行加锁

Gap Lock锁范围：（-∞，10）（10，20）（20，50）（50，+∞）

Next-Key Lock锁范围：（-∞，10] （10，20] （20，50] （50，+∞）

当查询的索引含有唯一属性时，InnoDB会对Next-Key Lock进行优化，将其降级为Record Lock，即仅锁住索引本身，而不是范围。

虽然避免了幻读问题，但是还有个特殊情况，感觉可以叫做“幻改”，即当前事务修改了本身并不能查询到的数据。这也是MVCC造成的假象，当前事务虽然查询不到其他事务提交的数据，但是可以对其他事务提交的数据进行修改。

显示全文