MYSQL事务(中)之隔离性与一致性原理详解

0 ~> 隔离性与一致性知识图谱

MySQL事务：隔离性与一致性
├─ 1 ~> 隔离性基础认知
│  ├─ 1.1 数据库三类并发场景
│  ├─ 1.2 隔离性的本质定义
│  └─ 1.3 隔离级别的设计逻辑
├─ 2 ~> 四种事务隔离级别详解
│  ├─ 2.1 读未提交（Read Uncommitted）
│  ├─ 2.2 读提交（Read Committed）
│  ├─ 2.3 可重复读（Repeatable Read）
│  └─ 2.4 串行化（Serializable）
├─ 3 ~> 隔离级别的查看与设置
│  ├─ 3.1 全局与会话隔离级别差异
│  └─ 3.2 标准SQL语法
├─ 4 ~> 并发异常与对应关系
│  ├─ 4.1 三类读异常
│  │  ├─ 脏读
│  │  ├─ 不可重复读
│  │  └─ 幻读
│  ├─ 4.2 两类更新丢失
│  └─ 4.3 隔离级别-问题对照表
├─ 5 ~> 隔离性实现原理基础
│  ├─ 5.1 MVCC多版本并发控制
│  └─ 5.2 锁机制基础
├─ 6 ~> 事务一致性（Consistency）
│  ├─ 6.1 一致性的定义
│  └─ 6.2 AID与C的因果关系
└─ 7 ~> 原笔记技术审计与纠错

1 ~> 隔离性基础认知

1.1 数据库三类并发场景

• 读 - 读：无任何并发安全问题，无需并发控制
• 读写：存在线程安全问题，会引发脏读、不可重复读、幻读三类隔离性异常
• 写写：存在线程安全问题，会引发更新丢失问题（第一类、第二类更新丢失）

1.2 隔离性的本质定义

• 核心定义：事务在执行过程中应当尽可能不受其他并发事务的干扰，每个事务只能看到符合自身时间线的数据视图
• 底层逻辑：事务具备「执行前 - 执行中 - 执行后」完整生命周期，隔离性保证事务执行阶段的内部操作不会被外部事务随意观测，是事务原子性的外在保障
• 类比理解：每个事务有独立的时间线，只能观测到自身生命周期内可见的数据，如同人无法看到自己出生前的完整历史

1.3 隔离级别的设计逻辑

• 核心矛盾：隔离严格程度与数据库并发性能成反比 —— 隔离越严格，数据安全性越高，但并发吞吐越低
• 设计原则：数据库不替业务做决策，只提供多级隔离方案，由开发者根据业务场景在「数据安全」与「并发性能」之间选择平衡点

2 ~> 四种事务隔离级别详解

2.1 读未提交（Read Uncommitted, RU）

• 定义：所有事务都可以看到其他并发事务尚未提交的执行结果
• 实现本质：几乎无锁，读写操作互不阻塞
• 存在问题：脏读、不可重复读、幻读全部存在
• 生产建议：实际生产环境严禁使用，仅用于原理验证实验
• 现象特征：事务 A 执行 insert/update 且未 commit 时，事务 B 可直接查询到修改后的数据

2.2 读提交（Read Committed, RC）

• 定义：一个事务只能看到其他已经提交的事务所做的修改
• 行业地位：Oracle、PostgreSQL 等大多数数据库的默认隔离级别
• 解决问题：彻底解决脏读
• 遗留问题：仍存在不可重复读、幻读
• 现象特征：事务 A 修改数据并 commit 后，处于执行中的事务 B 再次查询即可看到最新数据；事务 A 未 commit 时，事务 B 完全看不到修改

2.3 可重复读（Repeatable Read, RR）

• 定义：确保同一个事务在整个执行周期内，多次执行相同查询语句，得到的数据行完全一致
• 行业地位：MySQL InnoDB 引擎的默认隔离级别
• 解决问题：彻底解决脏读、不可重复读
• 幻读说明：
  • 标准 SQL 规范中的 RR 级别仍存在幻读问题
  • MySQL InnoDB 做了增强：快照读场景通过事务级快照避免幻读；当前读（加锁读）场景通过 Next-Key 锁（间隙锁 + 行锁）防止幻读
• 现象特征：事务 A 完成增删改并提交后，只要事务 B 未结束，事务 B 内的查询始终看到事务启动时的快照数据

2.4 串行化（Serializable）

• 定义：事务最高隔离级别，强制所有事务按到来顺序串行执行，彻底消除并发冲突
• 实现方式：普通 SELECT 会被隐式转为共享锁读，增删改加排他锁，读写互斥、写写互斥
• 解决问题：彻底解决脏读、不可重复读、幻读所有异常
• 弊端：并发性能极差，极易出现锁等待超时与死锁
• 生产建议：实际生产环境基本不使用
• 现象特征：事务 A 开启并查询数据后，事务 B 对同表执行增删改会被阻塞，直到事务 A 提交或回滚

3 ~> 隔离级别的查看与设置

3.1 全局与会话隔离级别差异

• 全局隔离级别（global）：作为所有新建会话的默认配置；修改后仅对后续新建立的连接生效，不影响当前已存在的连接
• 会话隔离级别（session）：仅对当前数据库连接生效；修改后立即生效，不影响其他任何连接
• 初始化规则：新建数据库连接时，会自动拷贝全局隔离级别作为当前会话的初始隔离级别

3.2 标准 SQL 语法

查看隔离级别

-- 查看全局隔离级别
SELECT @@global.tx_isolation;
-- 查看当前会话隔离级别
SELECT @@session.tx_isolation;
-- 简写形式，默认查看会话隔离级别
SELECT @@tx_isolation;

兼容性说明：MySQL 8.0 版本中 tx_isolation 变量已被废弃，替换为 transaction_isolation；5.7 版本中使用 tx_isolation 会触发警告，开发与面试中需注意版本差异。

设置隔离级别

-- 设置当前会话隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE};
-- 设置全局隔离级别
SET GLOBAL TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE};

4 ~> 并发异常与对应关系

4.1 三类读异常

4.1.1 脏读（Dirty Read）

• 定义：一个事务在执行过程中，读取到了另一个并发事务尚未提交的修改数据
• 本质：读取了事务的中间状态数据，若对方事务回滚，该数据即为无效脏数据
• 发生级别：仅读未提交级别

4.1.2 不可重复读（Non-Repeatable Read）

• 定义：同一个事务内，多次执行相同查询，由于其他并发事务提交了修改 / 删除操作，导致两次查询的数据值不一致
• 侧重点：针对数据的修改（update）与删除（delete），聚焦于数据内容的变化
• 发生级别：读未提交、读提交级别

4.1.3 幻读（Phantom Read）

• 定义：同一个事务内，多次执行相同范围查询，由于其他并发事务提交了插入操作，导致两次查询的记录行数不一致
• 侧重点：针对数据的新增（insert），聚焦于记录数量的变化
• 发生级别：标准 SQL 下读未提交、读提交、可重复读均存在；MySQL InnoDB 的 RR 级别做了增强优化

4.2 两类更新丢失

• 第一类更新丢失（回滚覆盖）：一个事务回滚时，覆盖了其他并发事务已经提交的更新；高隔离级别已自动避免
• 第二类更新丢失（提交覆盖）：一个事务提交时，覆盖了其他并发事务已经提交的更新；所有数据库隔离级别都无法自动避免，需业务层通过乐观锁或悲观锁解决
• 重要结论：MVCC 无法解决更新丢失问题，写写冲突必须通过锁机制处理

4.3 隔离级别 - 问题对照表

*注：标准 SQL 规范中 RR 级别存在幻读；MySQL InnoDB 的 RR 级别在快照读场景无幻读，当前读场景通过 Next-Key 锁防止幻读。

5 ~> 隔离性实现原理基础

5.1 MVCC（多版本并发控制）

• 定位：解决读写冲突的无锁并发控制方案，实现读操作不阻塞写、写操作不阻塞读，大幅提升数据库并发读写性能
• 核心思想：为事务分配单向增长的事务 ID，为每次数据修改保存关联事务 ID 的版本；读操作只读事务开始前的数据库快照，不与写操作竞争锁
• 能力边界：可解决脏读、不可重复读，无法单独解决幻读与更新丢失
• 三大核心前提：
  • 三个记录隐藏字段
    1. DB_TRX_ID（6 字节）：最近一次创建或修改该记录的事务 ID
    2. DB_ROLL_PTR（7 字节）：回滚指针，指向该记录的上一个历史版本，数据存储于 undo log
    3. DB_ROW_ID：隐藏主键，表无显式主键时自动生成
  • undo 日志：维护数据的历史版本链，支撑事务回滚与 MVCC 快照读取
  • Read View（读视图）：判断当前事务可见哪些数据版本的规则集；RC 与 RR 的核心差异就在于 Read View 的生成时机

5.2 锁机制基础

• 隔离性本质通过锁实现，不同隔离级别对应不同的锁策略
• 常见锁类型：表锁、行锁、读锁（共享锁）、写锁（排他锁）、间隙锁（GAP）、Next-Key 锁（间隙锁 + 行锁）
• 读写并发场景：读走 MVCC 无锁快照，写加行锁，读写互不阻塞
• 写写并发场景：必须加锁互斥，保证同一行数据同一时间只有一个事务执行修改

6 ~> 事务一致性（Consistency）

6.1 一致性的定义

• 核心定义：事务执行的结果，必须使数据库从一个一致性状态变迁到另一个一致性状态；数据库只包含成功提交的结果时，处于一致性状态
• 本质属性：一致性是业务层面的目标，而非纯技术属性；数据库仅提供技术支撑，最终的数据一致性必须由正确的业务逻辑保障
• 典型示例：转账场景中，转账前后两个账户的总金额保持不变，即为业务一致性

6.2 AID 与 C 的因果关系

结论：原子性（Atomicity）、隔离性（Isolation）、持久性（Durability）是「因」，一致性（Consistency）是「果」

• 补充说明：仅靠数据库技术无法完全保证一致性，必须结合正确的业务逻辑才能实现数据的最终一致。

到此这篇关于MYSQL事务(中)之隔离性与一致性原理详解的文章就介绍到这了,更多相关mysql隔离性与一致性内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论