我要评论在数据库管理系统中，事务隔离级别（transaction isolation levels）决定了事务之间如何相互隔离，以防止数据不一致和其他并发问题。mysql 提供了四种标准的事务隔离级别，每种级别在并发性能和数据一致性之间有不同的权衡。本文将详细介绍这四种隔离级别，包括它们的定义、特点、优缺点以及适用场景。
1. 事务隔离级别的概念
事务隔离级别定义了事务在执行过程中如何与其他事务隔离，以确保数据的完整性和一致性。不同的隔离级别通过不同的锁机制和并发控制策略来实现，从而在并发性能和数据一致性之间取得平衡。
2. mysql 的四种事务隔离级别
mysql 支持 ansi sql 标准定义的四种事务隔离级别，按照隔离程度从低到高依次为：
- read uncommitted（读未提交）
- read committed（读已提交）
- repeatable read（可重复读）
- serializable（串行化）
脏读就是一个事务读取到了另一个事务还没有提交的数据
不可重复度就是一个事务两次相同的sql,查询结果返回的结果却不一样,由于另外一个事务修改并提交导致的
幻读就是插入的时候提示已经有了,但是查询的时候是空的
2.1 read uncommitted（读未提交）
定义
在此隔离级别下，事务可以读取其他事务尚未提交的修改（脏读）。这意味着一个事务可以看到另一个事务尚未提交的中间状态数据。
特点
- 允许脏读：事务可以读取其他事务未提交的修改。
- 并发性能高：由于锁的粒度较小，减少了锁竞争，提高了并发性能。
- 数据一致性差：容易出现脏读、不可重复读和幻读问题。
优点
- 高并发：适用于对并发性能要求极高，且可以容忍一定程度数据不一致的场景。
缺点
- 数据不一致：可能导致脏读，影响数据的准确性和一致性。
- 不适合大多数应用：由于数据不一致的风险，通常不推荐在生产环境中使用。
适用场景
- 数据准确性要求不高，且对并发性能有极高要求的场景（如某些实时数据分析）。
示例
假设有两个事务 t1 和 t2：
- t1 修改了一行数据但尚未提交。
- t2 在 t1 提交前读取了该行数据，看到了 t1 的未提交修改（脏读）。
2.2 read committed（读已提交）
定义
在此隔离级别下，事务只能读取已经提交的其他事务所做的修改。每个查询只会看到在该查询开始之前已经提交的数据。
特点
- 防止脏读：事务不会读取其他事务未提交的修改。
- 允许不可重复读：同一个事务在不同时间执行相同的查询可能会看到不同的结果，因为其他事务可能已经提交了修改。
- 并发性能较高：相比 serializable，减少了锁的持有时间，提高了并发性能。
优点
- 避免脏读：确保事务不会读取到未提交的脏数据。
- 适中的并发性能：适用于大多数需要一定数据一致性的应用场景。
缺点
- 可能出现不可重复读：同一事务多次读取同一数据可能得到不同结果。
- 仍可能出现幻读：在某些情况下，事务可能会看到其他事务插入的新行。
适用场景
- 大多数在线事务处理（oltp）系统，需要保证数据的基本一致性，同时要求较高的并发性能。
示例
- t1 读取一行数据。
- t2 修改并提交该行数据。
- t1 再次读取同一行数据，看到 t2 的修改（不可重复读）。
2.3 repeatable read（可重复读）
定义
在此隔离级别下，事务在执行期间多次读取同一数据时，会看到一致的结果，即使其他事务已经修改了这些数据。mysql 的 innodb 存储引擎通过多版本并发控制（mvcc）实现这一点。
特点
- 防止脏读和不可重复读：事务在整个执行过程中看到的数据是一致的。
- 防止幻读（部分）：在 mysql 的 innodb 中，通过间隙锁（gap locks）防止幻读，但在某些情况下仍可能出现幻读。
- 并发性能适中：相比 read committed，进一步减少了不可重复读的问题，但锁的粒度较大，可能影响并发性能。
优点
- 高度一致性：确保事务多次读取同一数据时的一致性。
- 防止大多数并发问题：避免了脏读、不可重复读和大部分幻读问题。
缺点
- 可能出现幻读：在某些复杂查询条件下，仍可能出现幻读。
- 锁的粒度较大：可能影响并发性能，尤其是在高并发环境下。
适用场景
- 需要高度数据一致性的应用，如金融系统、订单处理系统等。
示例
- t1 开始一个事务并读取某范围内的行。
- t2 在该范围内插入新行并提交。
- t1 再次读取同一范围的行，不会看到 t2 插入的新行（防止幻读，但在某些条件下仍可能看到）。
2.4 serializable（串行化）
定义
这是最高的隔离级别，要求事务必须顺序执行，以避免并发问题。在此级别下，事务会对读取的数据加锁，防止其他事务对其进行修改或插入。
特点
- 完全防止并发问题：防止脏读、不可重复读和幻读。
- 事务串行执行：实际上将并发事务转换为串行执行，确保数据的一致性。
- 并发性能低：由于事务需要等待彼此完成，严重限制了并发性能。
优点
- 最高的数据一致性：确保在任何情况下都不会出现并发问题。
- 简单实现：不需要复杂的并发控制机制。
缺点
- 极低的并发性能：事务需要串行执行，极大地影响了系统的吞吐量和响应时间。
- 容易造成锁争用和死锁：高并发环境下容易导致锁等待和死锁。
适用场景
- 对数据一致性要求极高的场景，且可以接受较低的并发性能，如银行交易系统。
示例
- t1 开始一个事务并读取某范围内的行。
- t2 尝试在该范围内插入新行，但由于 t1 的锁，t2 必须等待 t1 完成。
- t1 完成后，t2 才能插入新行，确保数据的一致性。
3. mysql 中的隔离级别设置
在 mysql 中，可以通过以下方式设置事务的隔离级别：
3.1 查看当前的隔离级别
show variables like 'transaction_isolation';
或者
select @@global.transaction_isolation, @@session.transaction_isolation;
3.2 设置全局隔离级别
设置全局隔离级别会影响所有新连接，当前已经存在的会话不会受到影响。
set global transaction isolation level serializable;
3.3 设置当前会话的隔离级别
设置当前会话的隔离级别，只影响当前会话及之后新建的子会话。
set session transaction isolation level read committed;
3.4 设置下一个事务的隔离级别
仅对下一个事务生效，事务结束后恢复到之前的隔离级别。
set transaction isolation level read uncommitted; start transaction; -- 事务内容 commit;
4. 不同隔离级别的并发问题对比
| 隔离级别 | 脏读（dirty read） | 不可重复读（non-repeatable read） | 幻读（phantom read） |
|---|---|---|---|
| read uncommitted | 可能发生 | 可能发生 | 可能发生 |
| read committed | 不会发生 | 可能发生 | 可能发生 |
| repeatable read | 不会发生 | 不会发生 | 可能发生（innodb 部分防止） |
| serializable | 不会发生 | 不会发生 | 不会发生 |
5. 实际案例分析
案例 1：读未提交导致脏读
场景：电商系统中，订单支付和库存扣减。
- t1（事务1）：开始支付订单，减少库存，但尚未提交。
- t2（事务2）：查询订单状态和库存，看到 t1 的未提交修改（库存减少）。
- t1：回滚事务，库存恢复，但 t2 已经基于脏数据进行了后续操作。
结果：库存数据不一致，可能导致超卖。
案例 2：读已提交避免脏读，但可能出现不可重复读
场景：银行转账系统，账户余额查询和更新。
- t1：查询账户 a 的余额。
- t2：向账户 a 转账，更新余额并提交。
- t1：再次查询账户 a 的余额，看到 t2 的修改（不可重复读）。
结果：虽然避免了脏读，但同一事务内多次读取同一数据得到不同结果，可能导致逻辑错误。
案例 3：可重复读保证一致性
场景：在线订票系统，查询和预订座位。
- t1：查询某趟列车的剩余座位，显示有空位。
- t2：在同一列车上预订一个座位并提交。
- t1：再次查询剩余座位，仍然显示之前的结果（不变），因为使用了可重复读。
结果：确保了 t1 在事务内看到的一致性，避免了不可重复读和幻读。
案例 4：串行化确保最高一致性
场景：股票交易系统，订单匹配和执行。
- t1：查询某股票的买卖盘，找到匹配的买单。
- t2：在同一时间尝试修改同一股票的买卖盘，但由于 t1 的锁，t2 必须等待。
- t1：完成订单匹配和执行后，t2 才能继续操作。
结果：确保了数据的高度一致性，避免了所有并发问题，但牺牲了并发性能。
到此这篇关于mysql中隔离级别的4种小结的文章就介绍到这了,更多相关mysql 隔离级别内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论