Mysql事务底层原理分析及说明

一、事务的概念

事务（Transaction）就是由一组 SQL 语句构成的逻辑工作单元。它就像是一个不可分割的整体，要么里面的操作全部成功，要么全部失败，用于在高并发场景下保证数据的一致性和完整性。

二、事务的特性

• 原子性（Atomicity）：当前事务的执行要么全部成功，要么全部失败。原子性由undo log日志来保证。
• 一致性（Consistency）：使用事务的最终目的，由原子性、隔离性、持久性及业务代码正确逻辑保证。
• 隔离性（Isolation）：在事务并发执行时，它们内部的操作互相不干扰，由MVCC来保证。
• 持久性（Durability）：一旦提交了事务，它对数据库的改变就是永久性的。持久性由redo log日志来保证。

三、事务的使用方法

在 MySQL 中，通常使用以下 SQL 语句来控制事务：

3.1 开启事务

-- 开启事务
start transaction;  -- 或者使用 begin;

3.2 执行一系列 SQL 操作

-- 执行一系列 sql 语句
select * from t where id > 1;
insert into t(a, b, c, d) values (3, 5, 5, 'beijing');

3.3 提交事务

-- 提交事务
commit;

3.4 回滚事务

-- 回滚事务
rollback;

注意：

MySQL 默认是 自动提交 (autocommit = 1) 模式。

这意味着你每执行一条 UPDATE 或 INSERT，它都会立即作为一个独立的事务提交。

如果要手动控制事务，必须先执行 START TRANSACTION 或将 autocommit 设为 0。

四、事务的隔离级别

MySQL InnoDB 存储引擎支持四种事务隔离级别：

1、读未提交（READ UNCOMMITTED）：一个事务还没提交时，它做的变更就能够被其他事务看到。可能会产生脏读、不可重复读和幻读问题。

2、读已提交（READ COMMITTED）：一个事务提交后，它做的变更才能被其他事务看到。

3、可重复读（REPEATABLE READ）：MySQL的默认隔离级别。一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。

4、串行化（SERIALIZABLE）：事务被强制串行执行，每个事务在执行时都会对其他事务影响的数据行进行加锁，从而避免并行访问。可以避免脏读、不可重复读和幻读问题，但并发性能最低。

查看和设置数据库的事务隔离级

-- 查看当前会话的隔离级别
select @@tx_isolation;

-- 查看全局的隔离级别
select @@global.tx_isolation;

-- 设置当前会话的事务隔离级别（设置全局隔离级别：将 SESSION 换为 GLOBAL）
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE

-- mysql8 查看当前会话的事务隔离级别
SELECT @@SESSION.TRANSACTION_ISOLATION;

-- mysql8 查看全局的事务隔离级别
select @@global.TRANSACTION_ISOLATION;

脏读：

• 一个事务（Transaction A）读取了另一个事务（Transaction B）已修改但未提交的数据。
• 如果事务 B 随后因为某种原因回滚（Rollback）了，那么事务 A 读到的数据就是无效的（即“脏”数据）

不可重复读：

• 针对同一行数据，指在同一个事务中，前后两次读取这行数据，读取的值不一样。
• 比如在事务 A 中，我第一次读取 ID=1 的记录，值是 100；事务 B 把这行改成了 200 并提交；我第二次读取 ID=1 的记录，发现值变成了 200。数据被改了。

幻读：

• 针对结果集的数量，指在同一个事务中，前后两次读取一个范围内的数据，获取的结果集的行数不一样。
• 比如如在事务 A 中，我第一次查“年龄 > 20”的所有记录，查出来 5 条；事务 B 插入了一条“年龄 = 25”的新记录并提交；我第二次再查“年龄 > 20”，发现出来了 6 条。多了一行。

4.1 读未提交

在这个级别下，一个事务可以读取到其他事务尚未提交（Commit）的修改。可能会产生脏读、不可重复读和幻读问题。

4.2 读已提交

一个事务提交后，其他事务才能看到变更的数据。读已提交隔离级别解决了脏读，但存在不可重复读、幻读现象。

4.3 可重复读

一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。该隔离级别可以解决脏读、不可重复读问题，但在特定场景下依然会存在幻读问题。

出现幻读的场景：

原因分析：

可重复读隔离级别下，会基于事务启动后第一次查询时建立的数据“快照”（Read View）来读取数据，它看不到其他事务在它之后插入或修改的任何数据。因此，在纯快照读的场景下，不会发生幻读。

但事务中存在如下 SQL 语句时，必须读取数据库中最新的、已提交的数据。为了保证数据一致性，它会忽略之前的快照，直接去读取当前数据库的最新状态。

• SELECT ... FOR UPDATE
• SELECT ... LOCK IN SHARE MODE
• UPDATE, DELETE, INSERT

上述例子中，T4 时刻，左边事务更新 id >  3 的记录，会忽略快照，而去数据库中查找最新的记录，从而查询到右边事务新增的记录，即更新了两条记录。

根据MVCC机制，修改的这两条记录的事务ID都会标记为左边事务的id，从而能在第三次查询中显示出来，即出现幻读。

解决方案：

在左边事务查询数据时增加读锁或写锁，阻止其他事务新增数据。

4.4 串行化

每个事务在执行时都会对其他事务影响的数据行进行加锁，从而避免并行访问。可以避免脏读、不可重复读和幻读问题，但并发性能最低。

五、事务的原理

5.1 核心概念

MVCC(Multi-Version Concurrency Control)多版本并发控制，通过保存数据的历史版本来实现并发控制，避免读写冲突，主要通过undo日志链来实现。

5.1.1 InnoDB 存储引擎的行格式

• DB_TRX_ID：最近修改事务ID
• DB_ROLL_PTR：回滚指针，指向 undo log 记录

每次事务对行数据进行修改时，都会新生成一行记录，并且 DB_TRX_ID 保存该事务的ID，DB_ROLL_PTR 保存上一次修改该行记录的 undo log 位置指针

5.1.2 ReadView 快照

事务读取时创建的视图，包含：

• creator_trx_id：创建者事务ID
• m_ids：活跃事务ID列表，不包含当前事务的ID
• min_trx_id：最小活跃事务ID
• max_trx_id：下一个要分配的事务ID

快照的过滤规则：

MVCC 在读取每一行数据时，会检查该行的版本号（trx_id）是否对当前事务可见。判断逻辑如下：

• 如果这行数据的 trx_id 等于当前事务的 ID（即是你自己修改的） -> 可见 ✅
• 如果这行数据的 trx_id 在快照的“活跃事务列表”中（即其他未提交事务修改的） -> 不可见 ❌
• 如果这行数据的 trx_id 小于快照中的最小版本号（即其他事务在快照创建前修改并提交的） -> 可见 ✅
• 如果这行数据的 trx_id 大于快照中的最大版本号（即其他事务在快照创建后修改的） -> 不可见 ❌

5.2 事务执行流程

事务执行流程如下:

①查询处理：客户端发送 SQL 请求到 MySQL Server 层

②数据加载：如果所需数据页不在 Buffer Pool 中，从磁盘加载到内存

③事务开始：执行 START TRANSACTION，分配事务 ID 并创建 Read View

④数据修改：在 Buffer Pool 中创建新版本数据，原数据写入 Undo Log

⑤日志记录：

• Undo Log：记录逻辑变化，支持 MVCC 和回滚
• Redo Log：记录物理变化，保证持久性
• Binlog：记录逻辑 SQL，用于主从复制和数据恢复

⑥两阶段提交：

• Prepare 阶段：Redo Log 写入磁盘并标记为 prepare 状态
• Commit 阶段：Binlog 写入磁盘，然后 Redo Log 标记为 commit 状态

⑦后台刷新：脏页由后台线程异步刷入磁盘

事务执行的内存结构与磁盘文件示意图：

5.3 隔离级别与MVCC关系

MVCC 主要用于实现 READ COMMITTED（读已提交）和 REPEATABLE READ（可重复读）这两种隔离级别。

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

最新评论