mysql的隔离级别，分别用来解决什么问题-优快云博客

本文链接：https://blog.youkuaiyun.com/sui_152/article/details/147173849

MySQL的事务隔离级别定义了多个并发事务之间的可见性和影响规则，用于平衡数据一致性与并发性能。通过合理选择隔离级别，可避免脏读、不可重复读、幻读等问题。以下是MySQL支持的四种隔离级别及其原理、问题与实战应用。

1. 四种隔离级别（从低到高）

隔离级别	脏读	不可重复读	幻读	实现机制
READ UNCOMMITTED	可能	可能	可能	无锁，直接读最新数据
READ COMMITTED (RC)	不可能	可能	可能	基于MVCC，每次读新快照
REPEATABLE READ (RR)	不可能	不可能	可能*	基于MVCC，事务内读同一快照
SERIALIZABLE	不可能	不可能	不可能	完全串行化，加锁阻塞

注：
幻读：在RR级别下，MySQL通过Next-Key Lock（间隙锁+行锁）实际避免了大部分幻读。
默认隔离级别：MySQL InnoDB引擎默认使用REPEATABLE READ。

2. 隔离级别的问题与示例

脏读（Dirty Read）
定义：事务A读取了事务B未提交的修改。

示例：

-- 事务A
UPDATE users SET balance = 100 WHERE id = 1;  -- 未提交

-- 事务B（READ UNCOMMITTED）
SELECT balance FROM users WHERE id = 1;  -- 读到100（脏数据）

不可重复读（Non-Repeatable Read）
定义：事务内多次读取同一数据，结果不一致（因其他事务提交了修改）。
示例：

-- 事务A（READ COMMITTED）
SELECT balance FROM users WHERE id = 1;  -- 第一次读：100

-- 事务B提交更新
UPDATE users SET balance = 200 WHERE id = 1; COMMIT;

-- 事务A再次读
SELECT balance FROM users WHERE id = 1;  -- 第二次读：200（不可重复）

幻读（Phantom Read）
定义：事务内多次查询同一条件，结果集行数不同（因其他事务提交了新增或删除）。

示例：

-- 事务A（REPEATABLE READ）
SELECT * FROM users WHERE age > 20;  -- 返回2条记录

-- 事务B插入新数据并提交
INSERT INTO users (name, age) VALUES ('Alice', 25); COMMIT;

-- 事务A再次查询
SELECT * FROM users WHERE age > 20;  -- 仍返回2条（RR下通过MVCC避免幻读）
-- 但若事务A执行更新操作，可能发现数据变化（需结合锁机制）。

3. 隔离级别的实现原理

MVCC（多版本并发控制）
核心思想：每个事务看到的是数据的历史快照，而非实时数据。

实现细节：

每行数据包含两个隐藏字段：DB_TRX_ID（事务ID）和DB_ROLL_PTR（回滚指针）。
事务启动时分配唯一ID，读取时仅访问版本号小于等于自身ID的数据。
ReadView机制：事务在读取时生成一致性视图，决定可见哪些版本的数据。

Next-Key Lock
作用：解决幻读问题，锁定索引记录及其间隙（Gap）。

示例：

-- 事务A（RR级别）
SELECT * FROM users WHERE age > 20 FOR UPDATE;  -- 锁定age>20的现有记录及间隙
-- 事务B尝试插入age=25的记录会被阻塞

4. 隔离级别设置与查看

查看当前隔离级别

SELECT @@transaction_isolation;  -- MySQL 8.0+
-- 或
SELECT @@tx_isolation;           -- MySQL 5.x

设置隔离级别

会话级设置：

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

全局设置（需权限）：

SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;

5. 实战建议

默认使用REPEATABLE READ：
- MySQL默认的RR级别通过MVCC和Next-Key Lock已解决大部分幻读问题，适合多数场景。
READ COMMITTED的适用场景：
- 高并发写入场景，需减少锁竞争（如电商库存扣减）。
- 允许不可重复读但对一致性要求不极端的业务。
SERIALIZABLE慎用：
- 完全串行化，性能差，仅用于强一致性需求（如金融交易）。
避免长事务：
- 长事务可能持有锁或保留大量历史快照，导致性能下降。

6. 示例场景分析

场景：银行转账

需求：转账过程需绝对一致，不允许中间状态被其他事务看到。

隔离级别选择：

RR或SERIALIZABLE：确保事务期间数据一致性。

加锁策略：使用SELECT … FOR UPDATE显式锁定账户行。

操作示例：

BEGIN;
-- 事务A（RR级别）
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;  -- 加行锁
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;