击穿 InnoDB 事务隔离级别：RC 与 RR 的底层实现、锁机制、MVCC 与幻读终极拆解

前言

业务中90%的数据不一致、死锁、并发异常问题，根源都在于对InnoDB事务隔离级别的底层实现理解不到位。本文从底层基石出发，彻底拆解InnoDB事务隔离的核心原理，重点对比RC（读已提交）与RR（可重复读）两大常用隔离级别的核心差异，配合可复现的实例，让你彻底搞懂底层逻辑，不再踩坑。

一、SQL标准隔离级别与读异常基础

1.1 三大读异常定义

• 脏读：事务A读取了事务B未提交的修改数据，若B回滚，A读取的数据即为脏数据。
• 不可重复读：同一个事务内，两次相同的主键查询，返回了不同的行内容（行数据被修改）。
• 幻读：同一个事务内，两次相同的范围查询，第二次返回了第一次没有的行（新增/删除行导致行数变化）。

1.2 SQL标准4个隔离级别

隔离级别	脏读	不可重复读	幻读
读未提交（READ UNCOMMITTED）	允许	允许	允许
读已提交（READ COMMITTED，RC）	禁止	允许	允许
可重复读（REPEATABLE READ，RR）	禁止	禁止	允许
串行化（SERIALIZABLE）	禁止	禁止	禁止

1.3 InnoDB对标准的实现差异

InnoDB默认隔离级别为RR，且在RR级别下，通过临键锁解决了SQL标准中允许的幻读问题，实现了更强的ACID隔离性。InnoDB的隔离级别实现，完全基于锁机制与MVCC（多版本并发控制） 两大核心基石，下面先拆解这两大核心组件。

二、InnoDB事务隔离的两大核心基石

2.1 锁机制：并发控制的核心屏障

InnoDB实现了行级锁与表级锁，核心锁类型与算法如下：

2.1.1 基础锁类型

• 共享锁（S锁） ：读锁，多个事务可同时加S锁，互斥X锁。语法：SELECT ... LOCK IN SHARE MODE
• 排他锁（X锁） ：写锁，同一时间只有一个事务可加X锁，互斥所有S/X锁。语法：SELECT ... FOR UPDATE，UPDATE/DELETE/INSERT会自动加X锁
• 意向锁（IS/IX） ：表级锁，用于快速判断表内是否存在行锁，避免全表扫描判断锁冲突。加行S/X锁前，必须先加对应的表级IS/IX锁，意向锁之间互相兼容，仅与表级S/X锁互斥。

2.1.2 行锁算法（核心）

InnoDB的行锁是加在索引上的，无有效索引会退化为表锁，核心行锁算法分为3种：

1. 记录锁（Record Lock） ：仅锁住索引中的某一行记录，仅针对存在的记录生效。
2. 间隙锁（Gap Lock） ：锁住索引记录之间的间隙，不锁记录本身，唯一作用是防止其他事务在间隙中插入数据，解决幻读。间隙锁之间互相兼容，仅与插入操作互斥。
3. 临键锁（Next-Key Lock） ：InnoDB RR级别默认的行锁算法，是记录锁+间隙锁的组合，锁住一个左开右闭的索引区间，彻底杜绝间隙插入，解决幻读。

2.1.3 临键锁的区间规则

InnoDB会将索引按照值排序，划分成多个左开右闭的区间，例如索引列有值10、20、30，会划分出4个临键区间： (-∞,10]、(10,20]、(20,30]、(30,+∞)

临键锁的退化规则（仅RR级别生效）：

• 唯一索引的等值查询，且记录存在：临键锁退化为记录锁，仅锁住目标行。
• 唯一索引的等值查询，且记录不存在：临键锁退化为间隙锁，锁住目标值所在的间隙。

2.2 MVCC：无锁并发控制的核心

MVCC（多版本并发控制），是InnoDB实现快照读的核心，通过数据的多版本链，让读操作不加锁，极大提升并发性能。

2.2.1 MVCC的底层依赖

MVCC完全依赖于聚簇索引的隐藏列、undo log版本链、Read View可见性判断三大组件。

1. 聚簇索引的隐藏列

InnoDB聚簇索引的每行数据，都包含3个隐藏列：

• trx_id：6字节，最后一次修改该行的事务ID（仅修改数据的事务会分配唯一递增的事务ID，只读事务不分配，trx_id为0）。
• roll_pointer：7字节，回滚指针，指向该行对应的undo log记录，通过undo log构建数据的版本链。
• DB_ROW_ID：6字节，隐藏主键，仅当表没有定义主键时生成，用于构建聚簇索引。

2. undo log版本链

每次对数据进行修改时，InnoDB都会生成一条undo log记录：

• 插入操作：生成insert undo log，事务提交后可直接删除。
• 修改/删除操作：生成update undo log，记录修改前的数据版本，用于事务回滚和MVCC的版本链构建，必须等到所有需要该版本的事务都提交后，才能被purge线程删除。

通过roll_pointer指针，所有历史版本的数据会形成一条单向链表，即版本链。版本链的头节点是当前最新的数据版本，尾节点是最早的历史版本。

3. Read View：可见性判断的核心

Read View是事务执行快照读时，生成的一个数据快照，记录了当前数据库中活跃的（未提交）事务信息，用于判断版本链中的哪个数据版本对当前事务可见。

Read View包含4个核心字段：

• m_ids：生成Read View时，数据库中所有活跃的读写事务ID列表。
• min_trx_id：m_ids中最小的事务ID，即当前活跃事务的最小ID。
• max_trx_id：生成Read View时，数据库将要分配的下一个事务ID，即全局最大事务ID+1。
• creator_trx_id：生成该Read View的当前事务ID。

版本可见性判断规则： 对于版本链中的某个数据版本，trx_id为修改该版本的事务ID：

1. 若trx_id == creator_trx_id：可见，当前事务自己修改的数据。
2. 若trx_id < min_trx_id：可见，修改该版本的事务在Read View生成前已经提交。
3. 若trx_id >= max_trx_id：不可见，修改该版本的事务在Read View生成后才开启。
4. 若min_trx_id <= trx_id < max_trx_id：若trx_id不在m_ids中，可见（事务已提交）；若在m_ids中，不可见（事务未提交）。

若当前版本不可见，就顺着roll_pointer找到下一个历史版本，重复上述判断，直到找到可见的版本，或者遍历完版本链返回空。

2.2.2 快照读与当前读

MVCC仅对快照读生效，两种读模式的定义：

• 快照读：普通的SELECT语句，不加锁，基于MVCC读取数据的可见版本，无锁并发，性能极高。
• 当前读：SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE、INSERT，读取数据的最新提交版本，并且对读取的记录加锁，基于锁机制实现并发控制。

三、RC与RR隔离级别的核心区别（终极拆解）

我们从锁机制、MVCC实现、幻读处理三个核心维度，彻底拆解RC与RR的区别，每个维度都配合可复现的实例。

3.1 锁机制的核心区别

RC与RR在锁机制上的差异，直接决定了两者的并发性能、死锁概率，核心差异有3点：

对比维度	RC隔离级别	RR隔离级别
行锁算法	仅支持记录锁，无间隙锁、临键锁	默认使用临键锁，符合条件时退化为记录锁/间隙锁
锁释放时机	不满足查询条件的行，语句执行完立即释放锁，无需等待事务提交	所有加锁的记录，必须等待事务提交/回滚后才释放
半一致性读	支持	不支持

3.1.1 行锁算法差异实例

准备工作：执行以下SQL创建测试表与数据，MySQL8.0环境可直接执行

CREATE TABLE `test_user` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `age` int NOT NULL COMMENT '年龄',
  `name` varchar(32) NOT NULL COMMENT '姓名',
  PRIMARY KEY (`id`),
  KEY `idx_age` (`age`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT '测试用户表';
INSERT INTO `test_user` (`id`, `age`, `name`) VALUES (10, 10, '张三'), (20, 20, '李四'), (30, 30, '王五');

实例1：RC级别下的行锁范围 步骤1：开启会话A，设置RC隔离级别，开启事务，执行带锁的范围查询

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
SELECT * FROM test_user WHERE age BETWEEN 10 AND 20 FOR UPDATE;

步骤2：开启会话B，执行插入操作，可正常执行，无阻塞

INSERT INTO test_user (id, age, name) VALUES (15, 15, '赵六');

原理：RC级别下，仅对age=10、age=20的两条记录加记录锁，不会锁住(10,20)的间隙，所以会话B可以正常插入age=15的记录，无锁冲突。

实例2：RR级别下的行锁范围 步骤1：开启会话A，设置RR隔离级别，开启事务，执行相同的带锁范围查询

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT * FROM test_user WHERE age BETWEEN 10 AND 20 FOR UPDATE;

步骤2：开启会话B，执行相同的插入操作，会被阻塞

INSERT INTO test_user (id, age, name) VALUES (15, 15, '赵六');

原理：RR级别下，InnoDB会对age BETWEEN 10 AND 20的范围加临键锁，锁住(-∞,10]、(10,20]、(20,30)的区间，包括间隙，所以会话B插入age=15的记录，会触发间隙锁冲突，被阻塞，直到会话A提交事务。

3.1.2 锁释放时机与半一致性读差异

半一致性读：RC级别下，UPDATE语句执行时，若遇到已经加了X锁的记录，InnoDB会先读取该记录的最新提交版本，判断是否符合UPDATE的WHERE条件，若不符合，就跳过该记录，不加锁；若符合，才会加锁等待。RR级别不支持半一致性读，遇到加锁的记录，直接加锁等待。

实例3：RC与RR的锁冲突概率对比 步骤1：初始化数据，恢复test_user表的初始数据

TRUNCATE TABLE test_user;
INSERT INTO `test_user` (`id`, `age`, `name`) VALUES (10, 10, '张三'), (20, 20, '李四'), (30, 30, '王五');

步骤2：开启会话A，设置RC隔离级别，开启事务，执行UPDATE语句

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
UPDATE test_user SET name='张三更新' WHERE age=10;

步骤3：开启会话B，设置RC隔离级别，开启事务，执行UPDATE语句，可正常执行，无阻塞

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
UPDATE test_user SET name='李四更新' WHERE age=20;
COMMIT;

原理：RC级别下，会话B的UPDATE语句扫描到age=10的记录时，发现已经加了X锁，通过半一致性读读取最新提交版本，判断age=10不符合WHERE条件，直接跳过，不加锁，仅对age=20的记录加锁，所以无冲突。

若将两个会话的隔离级别改为RR，步骤3的UPDATE语句会被阻塞，因为RR级别不支持半一致性读，会话B扫描到age=10的记录时，不管是否符合条件，都会加X锁等待，直到会话A提交事务。

3.2 MVCC实现的核心区别

RC与RR的MVCC实现，可见性判断规则完全一致，核心差异在于Read View的生成时机，这也是不可重复读问题的根源。

隔离级别	Read View生成时机
RC	事务中每次执行快照读（普通SELECT） 时，都会重新生成一个全新的Read View
RR	事务中第一次执行快照读（普通SELECT） 时，生成一个Read View，整个事务生命周期内复用该Read View

3.2.1 不可重复读的实例验证

实例4：RC级别下的不可重复读 步骤1：初始化数据，恢复test_user表初始数据

TRUNCATE TABLE test_user;
INSERT INTO `test_user` (`id`, `age`, `name`) VALUES (10, 10, '张三'), (20, 20, '李四'), (30, 30, '王五');

步骤2：开启会话A，设置RC隔离级别，开启事务，执行第一次快照读

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
SELECT * FROM test_user WHERE id=10;

执行结果：id=10，age=10，name=张三

步骤3：开启会话B，更新id=10的记录，提交事务

BEGIN;
UPDATE test_user SET age=11 WHERE id=10;
COMMIT;

步骤4：会话A执行第二次相同的快照读

SELECT * FROM test_user WHERE id=10;

执行结果：id=10，age=11，name=张三，出现不可重复读。

原理：RC级别下，会话A的两次SELECT，都生成了新的Read View。第二次生成Read View时，会话B的事务已经提交，所以会话B修改的版本对会话A可见，导致两次查询结果不一致。

实例5：RR级别下的可重复读保证 步骤1：初始化数据，恢复test_user表初始数据 步骤2：开启会话A，设置RR隔离级别，开启事务，执行第一次快照读

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT * FROM test_user WHERE id=10;

执行结果：id=10，age=10，name=张三

步骤3：开启会话B，更新id=10的记录，提交事务

BEGIN;
UPDATE test_user SET age=11 WHERE id=10;
COMMIT;

步骤4：会话A执行第二次相同的快照读

SELECT * FROM test_user WHERE id=10;

执行结果：id=10，age=10，name=张三，实现了可重复读。

原理：RR级别下，会话A第一次SELECT时生成了Read View，整个事务内复用该Read View。会话B的事务是在Read View生成之后提交的，所以修改的版本对会话A不可见，两次查询结果完全一致。

3.3 幻读处理的核心区别

首先明确：幻读的核心是范围查询的行数量变化，而非行内容变化，不可重复读针对的是行内容修改，幻读针对的是新增/删除行导致的范围查询结果变化。

RC与RR在幻读处理上的核心差异，分为快照读和当前读两个场景：

场景	RC隔离级别	RR隔离级别
快照读（普通SELECT）	每次生成新的Read View，会出现幻读	复用第一次的Read View，不会出现幻读
当前读（加锁读/写操作）	仅记录锁，无间隙锁，会出现幻读	临键锁锁住范围与间隙，彻底杜绝幻读

3.3.1 幻读的实例验证

实例6：RC级别下当前读的幻读 步骤1：初始化数据，恢复test_user表初始数据

TRUNCATE TABLE test_user;
INSERT INTO `test_user` (`id`, `age`, `name`) VALUES (10, 10, '张三'), (20, 20, '李四'), (30, 30, '王五');

步骤2：开启会话A，设置RC隔离级别，开启事务，执行第一次当前读

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
SELECT * FROM test_user WHERE age BETWEEN 10 AND 30 FOR UPDATE;

执行结果：3条记录，id=10、20、30

步骤3：开启会话B，插入一条符合范围的记录，提交事务

BEGIN;
INSERT INTO test_user (id, age, name) VALUES (25, 25, '赵六');
COMMIT;

步骤4：会话A执行第二次相同的当前读

SELECT * FROM test_user WHERE age BETWEEN 10 AND 30 FOR UPDATE;

执行结果：4条记录，多了id=25的行，出现幻读。

原理：RC级别下，会话A的当前读仅对age=10、20、30的三条记录加记录锁，不会锁住间隙，所以会话B可以插入age=25的记录，导致会话A第二次当前读出现了新的行，触发幻读。

实例7：RR级别下对幻读的彻底解决 步骤1：初始化数据，恢复test_user表初始数据 步骤2：开启会话A，设置RR隔离级别，开启事务，执行第一次当前读

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT * FROM test_user WHERE age BETWEEN 10 AND 30 FOR UPDATE;

执行结果：3条记录，id=10、20、30

步骤3：开启会话B，执行相同的插入操作，会被阻塞

INSERT INTO test_user (id, age, name) VALUES (25, 25, '赵六');

原理：RR级别下，会话A的当前读会对age BETWEEN 10 AND 30的范围加临键锁，锁住(-∞,10]、(10,20]、(20,30]、(30,+∞)的所有区间，包括间隙，所以会话B插入age=25的记录，会触发间隙锁冲突，被阻塞，直到会话A提交事务，彻底杜绝了幻读。

四、核心流程图与架构图

4.1 Read View可见性判断流程图

4.2 RC与RR的Read View生成时机对比图

4.3 临键锁区间示意图

五、Java实战：基于MyBatis-Plus验证隔离级别差异

5.1 项目依赖配置

pom.xml核心依赖：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.2.5</version>
        <relativePath/>
    </parent>
    <groupId>com.jam.demo</groupId>
    <artifactId>innodb-isolation-demo</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>innodb-isolation-demo</name>
    <properties>
        <java.version>17</java.version>
        <mybatis-plus.version>3.5.7</mybatis-plus.version>
        <fastjson2.version>2.0.52</fastjson2.version>
        <guava.version>33.1.0-jre</guava.version>
        <lombok.version>1.18.32</lombok.version>
        <springdoc.version>2.5.0</springdoc.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jdbc</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-validation</artifactId>
        </dependency>
        <dependency>
            <groupId>com.baomidou</groupId>
            <artifactId>mybatis-plus-boot-starter</artifactId>
            <version>${mybatis-plus.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springdoc</groupId>
            <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
            <version>${springdoc.version}</version>
        </dependency>
        <dependency>
            <groupId>com.mysql</groupId>
            <artifactId>mysql-connector-j</artifactId>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>${lombok.version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.alibaba.fastjson2</groupId>
            <artifactId>fastjson2</artifactId>
            <version>${fastjson2.version}</version>
        </dependency>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>${guava.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <excludes>
                        <exclude>
                            <groupId>org.projectlombok</groupId>
                            <artifactId>lombok</artifactId>
                        </exclude>
                    </excludes>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

5.2 配置文件

application.yml：

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://127.0.0.1:3306/test_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: root
  jackson:
    default-property-inclusion: non_null
mybatis-plus:
  mapper-locations: classpath*:/mapper/**/*.xml
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
springdoc:
  swagger-ui:
    path: /swagger-ui.html
    enabled: true
  api-docs:
    enabled: true

5.3 实体类

package com.jam.demo.entity;

import com.baomidou.mybatisplus.annotation.IdType;
import com.baomidou.mybatisplus.annotation.TableId;
import com.baomidou.mybatisplus.annotation.TableName;
import io.swagger.v3.oas.annotations.media.Schema;
import lombok.Data;

import java.io.Serial;
import java.io.Serializable;

/**
 * 测试用户实体类
 * @author ken
 */
@Data
@TableName("test_user")
@Schema(description = "测试用户实体")
public class TestUser implements Serializable {

    @Serial
    private static final long serialVersionUID = 1L;

    @TableId(type = IdType.AUTO)
    @Schema(description = "主键ID", example = "1")
    private Long id;

    @Schema(description = "年龄", example = "20")
    private Integer age;

    @Schema(description = "姓名", example = "张三")
    private String name;
}

5.4 Mapper接口

package com.jam.demo.mapper;

import com.baomidou.mybatisplus.core.mapper.BaseMapper;
import com.jam.demo.entity.TestUser;
import org.apache.ibatis.annotations.Param;
import org.apache.ibatis.annotations.Select;
import org.apache.ibatis.annotations.Update;

import java.util.List;

/**
 * 测试用户Mapper接口
 * @author ken
 */
public interface TestUserMapper extends BaseMapper<TestUser> {

    /**
     * 带排他锁的范围查询
     * @param minAge 最小年龄
     * @param maxAge 最大年龄
     * @return 符合条件的用户列表
     */
    @Select("SELECT * FROM test_user WHERE age BETWEEN #{minAge} AND #{maxAge} FOR UPDATE")
    List<TestUser> selectByAgeRangeForUpdate(@Param("minAge") Integer minAge, @Param("maxAge") Integer maxAge);

    /**
     * 更新用户年龄
     * @param id 用户ID
     * @param age 新年龄
     * @return 影响行数
     */
    @Update("UPDATE test_user SET age = #{age} WHERE id = #{id}")
    int updateAgeById(@Param("id") Long id, @Param("age") Integer age);
}

5.5 服务层实现

package com.jam.demo.service;

import com.jam.demo.entity.TestUser;
import com.jam.demo.mapper.TestUserMapper;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;
import org.springframework.transaction.TransactionDefinition;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.support.TransactionCallback;
import org.springframework.transaction.support.TransactionTemplate;
import org.springframework.util.CollectionUtils;

import jakarta.annotation.Resource;
import java.util.List;
import java.util.concurrent.CountDownLatch;

/**
 * 事务隔离级别测试服务
 * @author ken
 */
@Slf4j
@Service
public class IsolationTestService {

    @Resource
    private TransactionTemplate transactionTemplate;

    @Resource
    private TestUserMapper testUserMapper;

    /**
     * 验证RC隔离级别下的不可重复读
     * @param userId 用户ID
     * @return 两次查询的结果
     */
    public String testRcUnrepeatableRead(Long userId) {
        transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);
        return transactionTemplate.execute(new TransactionCallback<String>() {
            @Override
            public String doInTransaction(TransactionStatus status) {
                log.info("RC事务开启，第一次查询用户ID:{}", userId);
                TestUser firstUser = testUserMapper.selectById(userId);
                String firstResult = firstUser.toString();
                log.info("第一次查询结果:{}", firstResult);

                try {
                    CountDownLatch countDownLatch = new CountDownLatch(1);
                    new Thread(() -> {
                        try {
                            log.info("异步线程开启，更新用户年龄");
                            transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);
                            transactionTemplate.execute(updateStatus -> {
                                testUserMapper.updateAgeById(userId, firstUser.getAge() + 1);
                                return 1;
                            });
                            log.info("异步线程更新完成，事务提交");
                        } finally {
                            countDownLatch.countDown();
                        }
                    }).start();
                    countDownLatch.await();
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    log.error("线程等待异常", e);
                    status.setRollbackOnly();
                    return "执行异常";
                }

                log.info("RC事务，第二次查询用户ID:{}", userId);
                TestUser secondUser = testUserMapper.selectById(userId);
                String secondResult = secondUser.toString();
                log.info("第二次查询结果:{}", secondResult);

                return String.format("第一次查询结果:%s, 第二次查询结果:%s", firstResult, secondResult);
            }
        });
    }

    /**
     * 验证RR隔离级别下的可重复读
     * @param userId 用户ID
     * @return 两次查询的结果
     */
    public String testRrRepeatableRead(Long userId) {
        transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_REPEATABLE_READ);
        return transactionTemplate.execute(new TransactionCallback<String>() {
            @Override
            public String doInTransaction(TransactionStatus status) {
                log.info("RR事务开启，第一次查询用户ID:{}", userId);
                TestUser firstUser = testUserMapper.selectById(userId);
                String firstResult = firstUser.toString();
                log.info("第一次查询结果:{}", firstResult);

                try {
                    CountDownLatch countDownLatch = new CountDownLatch(1);
                    new Thread(() -> {
                        try {
                            log.info("异步线程开启，更新用户年龄");
                            transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);
                            transactionTemplate.execute(updateStatus -> {
                                testUserMapper.updateAgeById(userId, firstUser.getAge() + 1);
                                return 1;
                            });
                            log.info("异步线程更新完成，事务提交");
                        } finally {
                            countDownLatch.countDown();
                        }
                    }).start();
                    countDownLatch.await();
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    log.error("线程等待异常", e);
                    status.setRollbackOnly();
                    return "执行异常";
                }

                log.info("RR事务，第二次查询用户ID:{}", userId);
                TestUser secondUser = testUserMapper.selectById(userId);
                String secondResult = secondUser.toString();
                log.info("第二次查询结果:{}", secondResult);

                return String.format("第一次查询结果:%s, 第二次查询结果:%s", firstResult, secondResult);
            }
        });
    }

    /**
     * 验证RC隔离级别下的幻读
     * @param minAge 最小年龄
     * @param maxAge 最大年龄
     * @return 两次查询的结果
     */
    public String testRcPhantomRead(Integer minAge, Integer maxAge) {
        transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);
        return transactionTemplate.execute(new TransactionCallback<String>() {
            @Override
            public String doInTransaction(TransactionStatus status) {
                log.info("RC事务开启，第一次范围查询年龄:{}-{}", minAge, maxAge);
                List<TestUser> firstList = testUserMapper.selectByAgeRangeForUpdate(minAge, maxAge);
                int firstCount = firstList.size();
                log.info("第一次查询数量:{}, 结果:{}", firstCount, firstList);

                try {
                    CountDownLatch countDownLatch = new CountDownLatch(1);
                    new Thread(() -> {
                        try {
                            log.info("异步线程开启，插入符合范围的用户");
                            transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);
                            transactionTemplate.execute(insertStatus -> {
                                TestUser newUser = new TestUser();
                                newUser.setAge((minAge + maxAge) / 2);
                                newUser.setName("新用户");
                                testUserMapper.insert(newUser);
                                return 1;
                            });
                            log.info("异步线程插入完成，事务提交");
                        } finally {
                            countDownLatch.countDown();
                        }
                    }).start();
                    countDownLatch.await();
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    log.error("线程等待异常", e);
                    status.setRollbackOnly();
                    return "执行异常";
                }

                log.info("RC事务，第二次范围查询年龄:{}-{}", minAge, maxAge);
                List<TestUser> secondList = testUserMapper.selectByAgeRangeForUpdate(minAge, maxAge);
                int secondCount = secondList.size();
                log.info("第二次查询数量:{}, 结果:{}", secondCount, secondList);

                return String.format("第一次查询数量:%d, 第二次查询数量:%d, 幻读发生:%s",
                        firstCount, secondCount, firstCount != secondCount);
            }
        });
    }
}

5.6 控制层实现

package com.jam.demo.controller;

import com.jam.demo.service.IsolationTestService;
import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.Parameter;
import io.swagger.v3.oas.annotations.tags.Tag;
import jakarta.annotation.Resource;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

/**
 * 事务隔离级别测试控制器
 * @author ken
 */
@RestController
@RequestMapping("/isolation")
@Tag(name = "事务隔离级别测试接口", description = "验证InnoDB RC与RR隔离级别的核心差异")
public class IsolationTestController {

    @Resource
    private IsolationTestService isolationTestService;

    @GetMapping("/rc/unrepeatable")
    @Operation(summary = "验证RC隔离级别下的不可重复读", description = "验证RC隔离级别下，两次相同查询返回不同结果的不可重复读现象")
    public String testRcUnrepeatableRead(
            @Parameter(description = "用户ID", example = "10", required = true)
            @RequestParam Long userId) {
        return isolationTestService.testRcUnrepeatableRead(userId);
    }

    @GetMapping("/rr/repeatable")
    @Operation(summary = "验证RR隔离级别下的可重复读", description = "验证RR隔离级别下，两次相同查询返回一致结果的可重复读保证")
    public String testRrRepeatableRead(
            @Parameter(description = "用户ID", example = "10", required = true)
            @RequestParam Long userId) {
        return isolationTestService.testRrRepeatableRead(userId);
    }

    @GetMapping("/rc/phantom")
    @Operation(summary = "验证RC隔离级别下的幻读", description = "验证RC隔离级别下，两次相同范围查询返回不同行数的幻读现象")
    public String testRcPhantomRead(
            @Parameter(description = "最小年龄", example = "10", required = true)
            @RequestParam Integer minAge,
            @Parameter(description = "最大年龄", example = "30", required = true)
            @RequestParam Integer maxAge) {
        return isolationTestService.testRcPhantomRead(minAge, maxAge);
    }
}

5.7 启动类

package com.jam.demo;

import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

/**
 * 项目启动类
 * @author ken
 */
@SpringBootApplication
@MapperScan("com.jam.demo.mapper")
public class InnodbIsolationDemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(InnodbIsolationDemoApplication.class, args);
    }
}

六、业务选型建议与避坑指南

6.1 RC与RR的选型建议

选型维度	推荐RC隔离级别	推荐RR隔离级别
核心诉求	高并发、低死锁概率、极致性能	强数据一致性、低业务复杂度
业务场景	互联网电商、社交、内容平台等绝大多数OLTP场景	金融支付、账务系统、库存管理等对数据一致性要求极高的场景
binlog格式	必须使用ROW格式，避免主从不一致	STATEMENT/ROW格式均可

6.2 高频避坑指南

1. RR级别下，无索引的更新会导致全表锁 若UPDATE/DELETE的WHERE条件没有有效索引，InnoDB无法定位到具体的行，会对全表所有记录加临键锁，整个表无法插入任何数据，并发完全阻塞，生产环境绝对禁止。
2. RC级别下，范围查询的加锁无法防止幻读 若业务需要在RC级别下保证范围查询的一致性，必须手动加锁，且接受并发下降的代价，否则会出现幻读导致的数据不一致。
3. RR级别下，事务中过早的快照读会导致数据版本过旧 RR级别下，第一次快照读生成的Read View会被整个事务复用，若事务开启后很久才执行业务操作，会导致读取到的数据是很久之前的版本，引发业务逻辑错误，建议RR级别下，事务开启后立即执行第一次快照读，且事务尽量短小。
4. 不要混用快照读与当前读 同一个事务内，若先执行快照读，再执行当前读，当前读会读取最新的提交版本，可能导致快照读与当前读的结果不一致，引发业务逻辑混乱，建议同一个事务内，要么全用快照读，要么全用当前读。

七、核心总结

本文从底层原理出发，彻底拆解了InnoDB事务隔离级别的实现，核心结论如下：

1. InnoDB的事务隔离，完全基于锁机制与MVCC两大核心基石，锁机制解决当前读的并发控制，MVCC解决快照读的无锁并发。
2. RC与RR的核心差异，本质上是锁的粒度与释放时机、Read View的生成时机的差异，这两个差异直接决定了两者的并发性能、一致性保证。
3. RC级别并发性能更高，死锁概率更低，是互联网业务的首选；RR级别数据一致性更强，适合金融等强一致性场景。
4. InnoDB的RR级别，通过MVCC解决了快照读的幻读，通过临键锁解决了当前读的幻读，实现了比SQL标准更强的隔离性。

所有的并发问题，本质上都是对隔离级别底层实现的理解不到位。只有彻底搞懂底层原理，才能写出高并发、高一致性的业务代码，彻底杜绝数据不一致、死锁等线上问题。