2024-11-22发表Database / SQL / MySQL12 分钟读完 (大约1795个字)

SQL事务隔离级别详解

为什么需要事务隔离级别？

在并发环境下，多个事务同时操作数据库时会产生各种并发问题。如果不进行隔离控制，可能会导致数据的不一致性。主要会出现以下问题：

1. 脏读（Dirty Read）

定义：一个事务读取到另一个事务未提交的数据
危害：可能导致业务决策建立在不可靠的数据之上

sequenceDiagram
    participant T1 as 事务1
    participant T2 as 事务2
    
    Note over T1,T2: 脏读示例场景
    T1->>T1: 开始事务
    T2->>T2: 开始事务
    T1->>T1: 查询账户余额 = 1000元
    T1->>T1: 更新余额 = 1000 - 200
    Note right of T1: 余额更新为800元(未提交)
    T2->>T2: 查询账户余额 = 800元
    Note right of T2: 读取到未提交数据(脏读)
    T1->>T1: 回滚事务
    Note right of T1: 余额恢复为1000元
    T2->>T2: 基于脏数据进行业务处理
    Note right of T2: 出现业务错误

2. 不可重复读（Non-repeatable Read）

定义：同一事务内多次读取同一数据集合，由于其他事务的修改提交，导致两次读取的结果不一致
危害：在同一事务内无法保证数据一致性，可能影响统计、汇总等操作的准确性

sequenceDiagram
    participant T1 as 事务1
    participant T2 as 事务2
    
    Note over T1,T2: 不可重复读示例场景
    T1->>T1: 开始事务
    T2->>T2: 开始事务
    T1->>T1: 第一次读取用户年龄 = 20岁
    T2->>T2: 更新用户年龄 = 21岁
    T2->>T2: 提交事务
    T1->>T1: 第二次读取用户年龄 = 21岁
    Note right of T1: 同一事务内两次读取结果不一致
    T1->>T1: 提交事务

3. 幻读（Phantom Read）

定义：同一事务内多次读取一个范围内的记录集合，由于其他事务的插入或删除操作，导致两次读取的记录数量不一致
危害：可能影响基于范围的统计结果，导致业务逻辑错误

sequenceDiagram
    participant T1 as 事务1
    participant T2 as 事务2
    
    Note over T1,T2: 幻读示例场景
    T1->>T1: 开始事务
    T2->>T2: 开始事务
    T1->>T1: 查询年龄>20的用户数量 = 2人
    T2->>T2: 插入一条年龄=25的新用户
    T2->>T2: 提交事务
    T1->>T1: 再次查询年龄>20的用户数量 = 3人
    Note right of T1: 出现幻读现象
    T1->>T1: 提交事务

SQL的四种隔离级别详解

1. 读未提交（Read Uncommitted）

最低的隔离级别，允许一个事务读取另一个事务未提交的数据变更。

sequenceDiagram
    participant T1 as 事务1
    participant T2 as 事务2
    
    Note over T1,T2: Read Uncommitted级别
    T1->>T1: 开始事务
    T2->>T2: 开始事务
    T1->>T1: 查询商品库存 = 100
    T2->>T2: 查询商品库存 = 100
    T1->>T1: 更新库存 = 90
    Note right of T1: 未提交更新
    T2->>T2: 查询商品库存 = 90
    Note right of T2: 读取到未提交数据
    T1->>T1: 回滚事务
    T2->>T2: 基于脏数据处理业务
    Note right of T2: 可能导致业务错误

特点：

可能出现脏读、不可重复读和幻读
性能最好，但数据一致性最差
实际应用中几乎不使用

2. 读已提交（Read Committed）

只允许读取已经提交的数据。

sequenceDiagram
    participant T1 as 事务1
    participant T2 as 事务2
    
    Note over T1,T2: Read Committed级别
    T1->>T1: 开始事务
    T2->>T2: 开始事务
    T1->>T1: 查询商品价格 = 100元
    T2->>T2: 更新商品价格 = 120元
    Note right of T2: 未提交更新
    T1->>T1: 再次查询价格 = 100元
    Note right of T1: 仍然是原价
    T2->>T2: 提交事务
    T1->>T1: 第三次查询价格 = 120元
    Note right of T1: 读取到已提交的新价格

特点：

解决了脏读问题
可能出现不可重复读和幻读
适用场景：
- 对实时性要求较高的业务
- 读写频繁的在线交易系统
- 大多数数据库的默认级别

3. 可重复读（Repeatable Read）

MySQL的默认隔离级别，在同一事务中保证多次读取同一数据的结果一致。

sequenceDiagram
    participant T1 as 事务1
    participant T2 as 事务2
    
    Note over T1,T2: Repeatable Read级别
    T1->>T1: 开始事务
    T2->>T2: 开始事务
    T1->>T1: 查询用户余额 = 1000元
    T2->>T2: 更新用户余额 = 800元
    T2->>T2: 提交事务
    T1->>T1: 再次查询余额 = 1000元
    Note right of T1: 可重复读保证
    T1->>T1: 提交事务
    T1->>T1: 开始新事务
    T1->>T1: 查询余额 = 800元
    Note right of T1: 新事务可见已提交的更新

特点：

解决了脏读、不可重复读问题
MySQL通过MVCC（多版本并发控制）实现
可能出现幻读（InnoDB引擎通过Next-Key Lock基本解决）
适用场景：
- 需要事务内数据一致性的业务
- 财务统计、报表生成等

4. 串行化（Serializable）

最高的隔离级别，完全串行执行事务。

sequenceDiagram
    participant T1 as 事务1
    participant T2 as 事务2
    
    Note over T1,T2: Serializable级别
    T1->>T1: 开始事务
    T1->>T1: 查询并锁定记录
    T2-->>T2: 尝试访问同一记录(等待)
    Note right of T2: 被阻塞
    T1->>T1: 更新记录
    T1->>T1: 提交事务
    T2->>T2: 继续执行
    Note right of T2: 串行访问

特点：

解决所有并发问题
通过加锁实现完全串行执行
性能最差，并发度最低
适用场景：
- 要求强一致性的金融交易
- 涉及重要资金的操作
- 并发量很低的关键业务

常用SQL默认的隔离级别

MySQL（InnoDB引擎）：默认隔离级别是 REPEATABLE READ。但是，由于MySQL的InnoDB存储引擎实现了多版本并发控制（MVCC），它在REPEATABLE READ级别上实际上可以避免幻读。
PostgreSQL：默认隔离级别是 READ COMMITTED。
SQL Server：默认隔离级别是 READ COMMITTED。
Oracle：默认隔离级别是 READ COMMITTED。
SQLite：默认隔离级别是 SERIALIZABLE，因为它是一个轻量级的数据库，通常用于嵌入式系统，所以它默认使用了最高的隔离级别以确保数据一致性。

如何选择合适的隔离级别？

业务要求分析：
- 数据一致性要求
- 实时性要求
- 并发压力
- 业务容错性
常见业务场景推荐：
- 一般OLTP系统：Read Committed
- 存在统计分析的系统：Repeatable Read
- 金融核心系统：Serializable
- 有实时性要求的查询：Read Committed
性能考虑：
- 隔离级别越高，并发性能越差
- 需要在一致性和性能之间找到平衡点

实践建议

合理使用事务：
- 事务尽可能短
- 避免长事务
- 减少事务涉及的数据量
隔离级别选择：
- 优先考虑Read Committed
- 特殊业务场景再提高隔离级别
- 避免过度使用Serializable
业务设计：
- 通过业务逻辑避免并发问题
- 使用乐观锁等机制补充
- 考虑数据一致性的最终一致性方案

#基础