文章目录
- 一、事务隔离级别简介
-
- [1、读未提交（Read Uncommitted）](#1、读未提交（Read Uncommitted）)
- [2、读已提交（Read Committed）](#2、读已提交（Read Committed）)
- [3、可重复读（Repeatable Read）](#3、可重复读（Repeatable Read）)
- 4、串行化（Serializable）
- 二、如何选择合适的事务隔离级别？
- 三、mvcc原理
- 四、总结
在数据库管理中，事务（Transaction）是保证数据一致性和系统可靠性的基本单元。事务隔离级别决定了多个并发事务之间如何相互作用以及它们访问数据的可见性。四种标准事务隔离级别： 读未提交 、 读已提交 、 可重复读 和 串行化 ，它们在确保数据一致性和并发性能之间做出了不同的权衡。
本文将通过案例分析这四种事务隔离级别的特点、优缺点，并帮助你理解如何根据实际业务场景选择合适的事务隔离级别。
一、事务隔离级别简介
事务隔离级别定义了不同事务之间的可见性。为了帮助理解这四个隔离级别的影响，我们通过一个具体的场景来分析。
场景描述：
假设我们有一个 student 表，包含学生的 id 和 age 信息。在这个表上，事务A和事务B并发执行如下操作：
- 事务A 执行：
SELECT * FROM student WHERE age > 20;，查询所有年龄大于20的学生记录。 - 事务B 执行：
INSERT INTO student (id, age) VALUES (3, 23);，插入一条新记录。
我们将分析在不同事务隔离级别下，事务A执行查询时的行为。
1、读未提交（Read Uncommitted）
在 读未提交 隔离级别下，事务A可以读取到事务B未提交的操作，甚至可以看到其他事务正在进行中的数据修改。这种隔离级别最弱，可能导致 脏读（Dirty Read）。
案例分析：
- 事务A 执行查询：
SELECT * FROM student WHERE age > 20;可能返回id=1, age=22和id=2, age=21。 - 事务B 执行插入操作：
INSERT INTO student (id, age) VALUES (3, 23);，并未提交。 - 事务A 再次执行查询：
SELECT * FROM student WHERE age > 20;会返回id=1, age=22、id=2, age=21和事务B尚未提交的id=3, age=23。
问题 ：因为事务A可以读取到事务B未提交的数据，这样就会发生 脏读，如果事务B最终回滚，事务A读取的脏数据就会消失，导致数据不一致。
优缺点：
- 优点：性能最佳，几乎没有锁开销，适用于读操作较多且对一致性要求不高的场景。
- 缺点：容易发生脏读，数据一致性无法保证。
适用场景：
- 日志记录、监控数据等对数据一致性要求较低的场景。
2、读已提交（Read Committed）
在 读已提交 隔离级别下，事务A只能读取已经提交的其他事务的数据。这样避免了脏读的问题，但可能会出现 不可重复读（Non-repeatable Read） 的问题，即同一事务中多次读取相同数据时，结果可能会不同。
案例分析：
- 事务A 执行查询：
SELECT * FROM student WHERE age > 20;返回id=1, age=22和id=2, age=21。 - 事务B 执行插入操作：
INSERT INTO student (id, age) VALUES (3, 23);，并提交。 - 事务A 再次执行查询：
SELECT * FROM student WHERE age > 20;会返回id=1, age=22、id=2, age=21和 事务B 提交后的新记录id=3, age=23。
问题 ：在第二次查询中，事务A看到的结果发生了变化，导致数据不一致，这就是 不可重复读。虽然事务A避免了脏读，但由于其他事务的提交，事务A的查询结果不同。
优缺点：
- 优点：避免了脏读，适用于对数据一致性要求不高的场景。
- 缺点：可能发生不可重复读，即在同一事务中，读取相同数据的结果不同。
适用场景：
- 查询频繁、对数据一致性要求较低的应用，如报告生成、数据汇总等。
3、可重复读（Repeatable Read）
可重复读 隔离级别比读已提交更高，事务A在执行期间会锁定读取的数据，确保该数据在整个事务生命周期内不会发生变化，从而避免 不可重复读 的问题。但在此级别下，仍然可能发生 幻读（Phantom Read）问题，即事务A查询的范围内，其他事务可能会插入新记录，导致查询结果发生变化。
案例分析：
- 事务A 执行查询：
SELECT * FROM student WHERE age > 20;返回id=1, age=22和id=2, age=21。 - 事务B 插入新记录：
INSERT INTO student (id, age) VALUES (3, 23);，并提交。 - 事务A 再次执行相同查询：
SELECT * FROM student WHERE age > 20;仍然只会返回id=1, age=22和id=2, age=21，不会看到事务B插入的新记录。
问题 ：尽管事务A避免了不可重复读，但它仍然无法看到事务B插入的新记录，导致查询结果没有及时更新，这就是 幻读。
优缺点：
- 优点：避免了脏读和不可重复读，适用于大多数需要保持一致性的应用。
- 缺点：可能发生幻读，并且在高并发的环境下，性能开销较大。
适用场景：
- 对数据一致性要求较高的应用，如库存管理、订单处理等。
4、串行化（Serializable）
串行化 是最高的事务隔离级别，事务A在执行时会锁定所有相关数据，确保其他事务无法对同一数据进行操作。它通过强制事务按顺序执行，完全避免了脏读、不可重复读和幻读问题。
案例分析：
- 事务A 执行查询：
SELECT * FROM student WHERE age > 20;返回id=1, age=22和id=2, age=21。 - 事务B 插入新记录：
INSERT INTO student (id, age) VALUES (3, 23);，但事务B会被阻塞，直到事务A完成。 - 事务A 完成后，事务B才能提交。
问题：在串行化隔离级别下，所有事务严格按照顺序执行，完全避免了幻读、不可重复读和脏读，但这种机制会导致严重的性能瓶颈，因为事务会相互阻塞。
优缺点：
- 优点：完全消除脏读、不可重复读和幻读，数据一致性最强。
- 缺点：性能开销最大，可能导致事务长时间阻塞，降低并发性。
适用场景：
- 对数据一致性要求极高的系统，如金融支付、银行转账等关键业务。
二、如何选择合适的事务隔离级别？
选择事务隔离级别时，首先要考虑你的应用对数据一致性 和并发性能的要求。以下是选择不同隔离级别时的一些建议：
- 读未提交：适用于对数据一致性要求不高的应用，性能优先，如日志记录、某些数据统计场景。
- 读已提交：适用于对一致性有一定要求但并发量较大的应用，如报告生成、数据查询等。
- 可重复读：适用于对数据一致性要求较高的应用，如库存管理、订单处理等，能确保数据的一致性。
- 串行化：适用于对一致性要求极高的场景，尤其是金融系统、转账等场景，但由于性能开销较大，通常只在低并发的情况下使用。
三、mvcc原理
什么是 MVCC？
MVCC 是 InnoDB 使用的多版本并发控制机制，通过维护数据的多个版本，让快照读在不加锁的情况下实现一致性读，从而提升并发性能。
核心目标是：读写不互相阻塞，快照读不加锁，还能读到某一时刻一致的数据。
快照读 vs 当前读
快照读使用 MVCC，不加锁，普通 SELECT 都是快照读，读到的是历史版本。
当前读不使用 MVCC，会加锁，读的是最新版本，包括 SELECT ... FOR UPDATE、UPDATE、DELETE 等操作。
两者的区别在于：快照读走版本链 + ReadView；当前读直接加锁读最新值。
MVCC 的三大核心组件
MVCC 依赖三部分：
第一，行记录的隐藏字段：trx_id 记录最近修改该行的事务 id，roll_pointer 指向 Undo Log 旧版本，构成版本链；
第二，Undo Log：存储旧版本数据，用于回滚和 MVCC 获取历史版本；
第三，ReadView：快照读时生成，用事务 id 判断版本可见性。
RC 每次快照读都会生成新 ReadView；RR 一个事务内复用同一个 ReadView。
RC 和 RR 的差异
RC（读已提交）每次 SELECT 都生成新的 ReadView，所以可能读到不同数据。
RR（可重复读）整个事务只使用第一次快照读的 ReadView，因此能保证可重复读，也是 InnoDB 默认隔离级别。
Redo Log vs Undo Log
Undo Log 用于回滚事务、保存旧版本，是 MVCC 版本链的核心。
Redo Log 用于崩溃恢复，保证已提交事务不会丢失。
Undo 是逻辑日志，Redo 是物理日志，功能完全不同。
四、总结
在生产环境中，选择合适的事务隔离级别是平衡数据一致性 和系统性能的关键。通过了解每个事务隔离级别的特点、优缺点和适用场景，你可以更好地满足业务需求，并确保系统在高并发环境下的稳定性。
- 低并发、高一致性要求的系统 ：使用 串行化 隔离级别。
- 高并发、较低一致性要求的系统 ：可以考虑 读已提交 或 可重复读 隔离级别。
- 对于性能至关重要的场景 ：可以使用 读未提交，但需要权衡数据一致性。
通过灵活选择事务隔离级别，你可以确保数据库的高效运行，同时满足应用对数据一致性和并发性的需求。