当前位置： 首页 > news >正文

事务隔离级别和传播方式

news 2025/7/25 11:55:38

事务隔离级别

事务隔离级别是数据库系统中控制事务间相互影响程度的重要机制。不同的隔离级别在数据一致性保证和系统性能之间提供不同的权衡选择。下面我将详细解析四种标准隔离级别、它们能解决的问题以及可能存在的并发问题。

一、四种标准隔离级别

1. 读未提交 (Read Uncommitted)

  • 定义：事务可以读取其他事务尚未提交的修改（“脏读”）
  • 实现方式：通常不施加读锁或读取最新版本（包括未提交的）
  • 特点：
    • 性能最好（几乎没有锁开销）
    • 数据一致性最差
  • 适用场景：统计类查询，对准确性要求不高但需要高性能的场景

2. 读已提交 (Read Committed)

  • 定义：事务只能读取其他事务已提交的修改
  • 实现方式：
    • 锁机制：读操作获取共享锁，语句执行完立即释放
    • MVCC：每个语句看到的是语句开始时的已提交快照
  • 特点：
    • 防止了脏读
    • 可能出现不可重复读和幻读
  • 适用场景：大多数数据库的默认隔离级别（如Oracle、PostgreSQL）

3. 可重复读 (Repeatable Read)

  • 定义：事务在整个过程中看到的数据与事务开始时一致
  • 实现方式：
    • 锁机制：读锁保持到事务结束
    • MVCC：整个事务看到事务开始时的已提交快照
  • 特点：
    • 防止了脏读和不可重复读
    • 可能出现幻读（但MySQL InnoDB通过间隙锁防止了幻读）
  • 适用场景：需要同一事务内多次读取结果一致的场景

4. 可串行化 (Serializable)

  • 定义：事务串行执行，完全隔离
  • 实现方式：
    • 锁机制：严格的锁协议（如范围锁）
    • MVCC：通过冲突检测实现串行化（如SSI）
  • 特点：
    • 防止所有并发问题
    • 性能最差（高锁等待）
  • 适用场景：金融交易等对数据一致性要求极高的场景

二、隔离级别解决的并发问题

1. 脏读 (Dirty Read)

  • 定义：读取到其他事务未提交的数据
  • 可能引发的问题：基于无效数据做出错误决策
  • 解决级别：读已提交及以上级别可防止

示例：

-- 事务A
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;  -- 未提交-- 事务B（读未提交级别）
BEGIN;
SELECT balance FROM accounts WHERE id = 1;  -- 读到A未提交的修改
-- 如果A回滚，B读到的就是无效数据

2. 不可重复读 (Non-repeatable Read)

  • 定义：同一事务内两次读取同一数据，结果不同
  • 可能引发的问题：事务内逻辑判断不一致
  • 解决级别：可重复读及以上级别可防止

示例：

-- 事务A
BEGIN;
SELECT balance FROM accounts WHERE id = 1;  -- 第一次读，返回1000-- 事务B
BEGIN;
UPDATE accounts SET balance = 900 WHERE id = 1;
COMMIT;-- 事务A
SELECT balance FROM accounts WHERE id = 1;  -- 第二次读，返回900
-- 同一事务内两次读取结果不同

3. 幻读 (Phantom Read)

  • 定义：同一事务内两次相同查询返回不同的行集合
  • 可能引发的问题：新增或删除的行影响事务逻辑
  • 解决级别：可串行化级别可完全防止（MySQL RR级别也防止）

示例：

-- 事务A
BEGIN;
SELECT * FROM accounts WHERE balance < 1000;  -- 返回id为1,2的两条记录-- 事务B
BEGIN;
INSERT INTO accounts(id, balance) VALUES(3, 800);
COMMIT;-- 事务A
SELECT * FROM accounts WHERE balance < 1000;  -- 返回id为1,2,3的三条记录
-- 多出了一条"幻影"记录

三、不同隔离级别的实现对比

锁机制实现

隔离级别读锁保持时间写锁保持时间防止问题
读未提交不获取或立即释放事务结束无
读已提交语句结束事务结束脏读
可重复读事务结束事务结束脏读、不可重复读
可串行化事务结束+范围锁事务结束脏读、不可重复读、幻读

MVCC实现

隔离级别快照时间点防止问题
读未提交读取最新版本无
读已提交语句开始时脏读
可重复读事务开始时脏读、不可重复读
可串行化事务开始时+冲突检测所有问题

四、MySQL InnoDB的特殊实现

MySQL的InnoDB引擎在可重复读(RR)级别下通过以下机制也防止了幻读：

  1. Next-Key Locking：结合记录锁和间隙锁

    • 记录锁：锁定索引记录
    • 间隙锁：锁定索引记录之间的间隙
    • 防止其他事务在锁定范围内插入新记录

  2. 示例：

-- 事务A（RR级别）
BEGIN;
SELECT * FROM accounts WHERE balance BETWEEN 800 AND 1000 FOR UPDATE;
-- 不仅锁定了balance=800和1000的记录，还锁定了800-1000之间的间隙-- 事务B
BEGIN;
INSERT INTO accounts(id, balance) VALUES(3, 900);  -- 会被阻塞

五、隔离级别选择建议

  1. 优先考虑读已提交：

    • 大多数应用的平衡选择
    • 良好的性能与适中的一致性保证

  2. 需要可重复读时：

    • 报表生成等需要一致性快照的场景
    • 金融系统中需要多次读取相同数据的操作

  3. 谨慎使用可串行化：

    • 仅用于对一致性要求极高的场景
    • 注意可能导致的性能问题和死锁

  4. 避免使用读未提交：

    • 除非明确知道风险且能接受不一致数据

六、实际案例分析

电商库存管理场景

问题场景：

  • 商品库存：100件
  • 用户A和用户B同时下单购买最后一件商品

不同隔离级别下的表现：

  1. 读未提交：

    -- 事务A
BEGIN;
SELECT stock FROM products WHERE id = 1;  -- 看到100
UPDATE products SET stock = stock - 1 WHERE id = 1;-- 事务B（同时执行）
BEGIN;
SELECT stock FROM products WHERE id = 1;  -- 可能看到A未提交的99
UPDATE products SET stock = stock - 1 WHERE id = 1;  -- 最终库存98，超卖

  2. 读已提交：

    -- 事务A
BEGIN;
SELECT stock FROM products WHERE id = 1;  -- 看到100
UPDATE products SET stock = stock - 1 WHERE id = 1;-- 事务B
BEGIN;
SELECT stock FROM products WHERE id = 1;  -- 看到100（A未提交）
UPDATE products SET stock = stock - 1 WHERE id = 1;  -- 等待A提交
-- 最终库存99，仍可能超卖

  3. 可重复读（带FOR UPDATE）：

    -- 事务A
BEGIN;
SELECT stock FROM products WHERE id = 1 FOR UPDATE;  -- 加排他锁
UPDATE products SET stock = stock - 1 WHERE id = 1;-- 事务B
BEGIN;
SELECT stock FROM products WHERE id = 1 FOR UPDATE;  -- 等待A释放锁
-- 最终库存99，不会超卖

  4. 可串行化：

    -- 自动序列化执行，性能差但保证安全

最佳实践：

-- 使用RR隔离级别+悲观锁
BEGIN;
SELECT stock FROM products WHERE id = 1 FOR UPDATE;
-- 业务逻辑检查
IF stock >= 1 THENUPDATE products SET stock = stock - 1 WHERE id = 1;-- 创建订单
END IF;
COMMIT;

七、总结

理解事务隔离级别需要掌握：

  1. 四种标准隔离级别及其特点
  2. 三种主要并发问题（脏读、不可重复读、幻读）
  3. 不同数据库的具体实现差异
  4. 根据业务需求选择合适的隔离级别

实际应用中，通常：

  • 默认使用读已提交
  • 需要更高一致性时使用可重复读+适当的锁机制
  • 极少情况下使用可串行化

不可重复读与幻读的区别详解

不可重复读(Non-repeatable Read)和幻读(Phantom Read)确实都是指在同一个事务内两次查询结果不一致的现象，但它们的本质区别在于不一致的类型和范围。理解这两种现象的差异对于正确选择事务隔离级别和设计并发控制策略至关重要。

核心区别对比表

对比维度不可重复读 (Non-repeatable Read)幻读 (Phantom Read)
操作对象同一行数据的值发生变化结果集的行数发生变化
数据变化已存在行的数据被更新新增或删除了满足条件的行
锁定范围行级锁即可防止需要范围锁或间隙锁
问题本质数据值的不可重复性数据集合的不可重复性
典型SQLUPDATE操作导致INSERT/DELETE操作导致
解决级别可重复读(Repeatable Read)及以上可串行化(Serializable)

深入解析区别

1. 操作对象不同

不可重复读：

  • 针对的是同一行数据的内容变化
  • 例如：事务内两次读取id=1的用户余额，结果不同（1000→900）

幻读：

  • 针对的是结果集的行数变化
  • 例如：事务内两次执行WHERE age>30的查询，第一次返回2行，第二次返回3行

2. 引发操作不同

不可重复读由UPDATE操作引起：

-- 事务A
SELECT balance FROM accounts WHERE id = 1; -- 返回1000-- 事务B
UPDATE accounts SET balance = 900 WHERE id = 1;-- 事务A
SELECT balance FROM accounts WHERE id = 1; -- 返回900（不可重复读）

幻读由INSERT/DELETE操作引起：

-- 事务A
SELECT * FROM accounts WHERE balance > 800; -- 返回id为1,2的两行-- 事务B
INSERT INTO accounts(id, balance) VALUES(3, 900);-- 事务A
SELECT * FROM accounts WHERE balance > 800; -- 返回id为1,2,3的三行（幻读）

3. 锁定机制需求不同

防止不可重复读：

  • 只需要锁定已存在的行
  • 例如：共享锁(S锁)保持到事务结束

防止幻读：

  • 需要锁定可能满足条件的范围
  • 例如：间隙锁(Gap Lock)锁定值区间
  • MySQL的Next-Key Lock(记录锁+间隙锁)就是为此设计

4. 实际案例对比

银行账户系统案例

不可重复读场景：

  1. 对账单生成事务查询账户余额：
    -- 事务A（上午9:00开始）
SELECT balance FROM accounts WHERE id = 1001; -- 余额5000
  2. 同时有转账事务修改余额：
    -- 事务B（9:01执行）
UPDATE accounts SET balance = 4000 WHERE id = 1001;
COMMIT;
  3. 对账单事务再次查询：
    -- 事务A（9:02再次查询）
SELECT balance FROM accounts WHERE id = 1001; -- 余额4000
-- 同一行数据值变化，不可重复读

幻读场景：

  1. 信贷审批事务查询负债账户：
    -- 事务A
SELECT COUNT(*) FROM accounts WHERE balance < 0; -- 返回3个负债账户
  2. 同时有开户事务创建新负债账户：
    -- 事务B
INSERT INTO accounts(id, balance) VALUES(1004, -500);
COMMIT;
  3. 信贷事务基于查询结果决定总额度：
    -- 事务A
SELECT COUNT(*) FROM accounts WHERE balance < 0; -- 现在返回4个
-- 结果集行数变化，幻读

5. 技术实现差异

可重复读隔离级别下：

  • 可以防止不可重复读（通过行锁或MVCC保持行值不变）
  • 但可能无法防止幻读（除非像MySQL那样实现间隙锁）

可串行化隔离级别：

  • 通过严格的锁协议防止所有并发问题
  • 包括：
    • 谓词锁（锁定查询条件涉及的范围）
    • 索引范围锁
    • 全表扫描时的表级锁

6. 对应用的影响

不可重复读的影响：

  • 导致事务内基于同一数据的逻辑判断不一致
  • 例如：基于第一次查询结果做计算，但第二次查询值已变

幻读的影响：

  • 导致事务对数据集合的整体认知错误
  • 例如：统计计数、存在性检查等操作不可靠
  • 更隐蔽但可能影响更大

特殊注意事项

  1. MySQL的独特实现：

    • InnoDB在RR级别通过Next-Key Locking也防止了幻读
    • 这与SQL标准不同（标准中RR允许幻读）

  2. MVCC下的表现：

    • 使用多版本并发控制时：
      • 不可重复读：读取事务开始时的行版本
      • 幻读：快照中看不到新插入的行

  3. 业务层面的区别：

    • 不可重复读影响"数据准确性"
    • 幻读影响"数据完整性"

如何选择解决方案

防止不可重复读

  1. 使用可重复读隔离级别
  2. 对关键查询添加FOR UPDATE（悲观锁）
  3. 使用乐观锁（版本号控制）

防止幻读

  1. 使用可串行化隔离级别（性能代价高）
  2. 在RR级别下使用适当的锁：
    SELECT * FROM table WHERE condition FOR UPDATE; -- MySQL会加间隙锁
  3. 应用层校验（如二次确认）

总结记忆技巧

  • “不可重复读”：记住"值变了"（同一行的值不可重复）
  • “幻读”：记住"行变了"（像幻觉一样多出/少了行）
  • 简单说：
    • 不可重复读 = 行内数据不一致
    • 幻读 = 结果集行数不一致

理解这两种现象的差异，能帮助您更精准地选择事务隔离级别和设计并发控制策略，在保证数据一致性的同时获得最佳性能。

事务传播行为

一、事务传播行为核心概念

事务传播行为定义了在多个事务方法相互调用时，事务如何传播的规则。Spring框架提供了7种传播行为，每种行为对应不同的应用场景：

传播行为类型说明适用场景
REQUIRED默认值。当前有事务则加入，没有则创建新事务大多数业务场景
SUPPORTS当前有事务则加入，没有则以非事务方式执行查询操作，可接受非事务执行
MANDATORY当前必须有事务，否则抛出异常强制要求调用方提供事务环境
REQUIRES_NEW总是创建新事务，暂停当前事务（如果存在）独立子操作（如审计日志）
NOT_SUPPORTED以非事务方式执行，暂停当前事务（如果存在）不要求事务的批量操作
NEVER以非事务方式执行，如果当前存在事务则抛出异常强制要求非事务环境
NESTED如果当前存在事务，则在嵌套事务内执行（可部分回滚）；否则同REQUIRED复杂业务流程中的可回滚子操作

二、传播行为与线程安全深度解析

1. 线程安全的核心挑战

事务资源绑定机制：

  • Spring使用TransactionSynchronizationManager管理事务资源
  • 基于ThreadLocal存储当前线程的事务上下文
  • 每个线程有独立的事务状态和数据库连接
// Spring事务资源管理核心逻辑
public abstract class TransactionSynchronizationManager {private static final ThreadLocal<Map<Object, Object>> resources = new NamedThreadLocal<>("Transactional resources");private static final ThreadLocal<Set<TransactionSynchronization>> synchronizations =new NamedThreadLocal<>("Transaction synchronizations");private static final ThreadLocal<String> currentTransactionName =new NamedThreadLocal<>("Current transaction name");// ... 其他状态管理
}

2. REQUIRED 传播行为

典型场景：

@Service
public class OrderService {@Transactional(propagation = Propagation.REQUIRED)public void createOrder(Order order) {// 操作1：保存订单orderRepository.save(order);// 操作2：更新库存inventoryService.updateStock(order.getItems());}
}@Service
public class InventoryService {@Transactional(propagation = Propagation.REQUIRED)public void updateStock(List<Item> items) {// 库存更新逻辑}
}

线程安全分析：

  1. 同一线程内共享同一个事务上下文
  2. 共用同一个数据库连接
  3. 所有操作在同一个物理事务中提交或回滚
  4. 安全：天然线程封闭，无并发问题

3. REQUIRES_NEW 传播行为

典型场景（审计日志）：

@Service
public class PaymentService {@Transactional(propagation = Propagation.REQUIRED)public void processPayment(Payment payment) {// 支付处理逻辑paymentRepository.save(payment);// 审计日志（独立事务）auditService.logAction("PAYMENT_PROCESSED", payment.getId());}
}@Service
public class AuditService {@Transactional(propagation = Propagation.REQUIRES_NEW)public void logAction(String action, Long entityId) {// 审计日志记录}
}

线程安全风险点：

// 错误示例：跨线程使用事务
@Transactional
public void parentMethod() {new Thread(() -> {// 子线程尝试使用事务childMethod(); }).start();
}@Transactional(propagation = Propagation.REQUIRES_NEW)
public void childMethod() {// 实际执行：// 1. 新线程无事务上下文// 2. 创建新连接执行（非预期行为）
}

风险分析：

  1. 子线程无法继承父线程的事务上下文
  2. 每个线程创建独立数据库连接
  3. 可能导致：
    • 连接泄露
    • 事务不完整
    • 数据不一致

4. NESTED 传播行为

实现机制：

  • 使用数据库保存点（SAVEPOINT）实现
  • 可部分回滚嵌套事务内的操作
  • 外层事务提交时统一提交
@Transactional
public void complexBusinessProcess() {// 步骤1：核心操作coreOperation();try {// 步骤2：嵌套事务操作nestedOperation();} catch (BusinessException e) {// 仅回滚嵌套操作，不影响核心操作}// 步骤3：后续操作
}@Transactional(propagation = Propagation.NESTED)
public void nestedOperation() {// 嵌套事务逻辑
}

线程安全注意事项：

  1. 必须在同一线程内执行
  2. 依赖JDBC 3.0+的保存点功能
  3. 不支持所有数据库（如MySQL的MyISAM引擎不支持）

三、多线程场景下的安全实践

1. 正确模式：异步任务+独立事务

@Service
public class ReportService {@Async // Spring异步执行@Transactional(propagation = Propagation.REQUIRES_NEW)public void generateReportAsync(Long reportId) {// 生成复杂报表（独立事务）}
}@RestController
public class ReportController {@PostMapping("/reports")public ResponseEntity<?> requestReport() {reportService.generateReportAsync(reportId);return ResponseEntity.accepted().build();}
}

配置要求：

@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {@Overridepublic Executor getAsyncExecutor() {ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();executor.setCorePoolSize(5);executor.setMaxPoolSize(10);executor.setQueueCapacity(25);executor.initialize();return executor;}
}

2. 线程池事务管理要点

  1. 连接泄露预防：

    @Bean
public DataSource dataSource() {HikariDataSource ds = new HikariDataSource();ds.setMaximumPoolSize(20); // 匹配线程池大小ds.setLeakDetectionThreshold(30000); // 泄漏检测return ds;
}

  2. 事务超时控制：

    @Transactional(propagation = Propagation.REQUIRES_NEW,timeout = 30 // 秒
)
public void timeSensitiveOperation() {// ...
}

3. 分布式事务场景

跨服务调用模式：

ClientServiceAServiceB开启事务调用（携带事务ID）执行结果提交/回滚ClientServiceAServiceB

实现方案选择：

  • Seata：AT/TCC模式
  • Spring Cloud：支持XA协议的事务管理器
  • Saga模式：补偿事务实现最终一致性

四、并发问题深度防御策略

1. 隔离级别与传播行为组合

场景推荐组合说明
金融交易REQUIRED + SERIALIZABLE最高隔离级别
报表生成REQUIRES_NEW + READ_COMMITTED独立事务+中等隔离
批量处理NOT_SUPPORTED + READ_UNCOMMITTED非事务+最低隔离
微服务调用NESTED + REPEATABLE_READ部分回滚+重复读

2. 悲观锁与乐观锁选择

悲观锁实现：

@Transactional
public void updateWithPessimisticLock(Long id) {Entity entity = entityRepository.findById(id, LockModeType.PESSIMISTIC_WRITE);// 业务处理entityRepository.save(entity);
}

乐观锁实现：

@Entity
public class Account {@Idprivate Long id;@Versionprivate Integer version;// ...
}@Transactional
public void updateWithOptimisticLock(Account account) {// 自动校验版本号accountRepository.save(account);
}

3. 死锁预防策略

  1. 访问顺序：统一资源访问顺序
  2. 超时机制：
    @Transactional(timeout = 10)
public void quickOperation() {...}
  3. 死锁检测：数据库级（InnoDB）或应用级检测

五、最佳实践总结

  1. 传播行为选择原则：

    • 80%场景使用REQUIRED
    • 独立操作使用REQUIRES_NEW
    • 复杂业务流程考虑NESTED

  2. 线程安全黄金法则：

    一个事务 = 一个线程 = 一个连接

  3. 多线程事务规范：

    • 使用@Async+REQUIRES_NEW
    • 配置合适线程池大小
    • 添加事务超时设置
    • 避免跨线程共享事务状态

  4. 事务设计注意事项：

    • 保持事务短小精悍
    • 避免事务中远程调用
    • 合理设置隔离级别
    • 重要操作添加重试机制

  5. 事务监控指标：

    • 事务平均执行时间
    • 事务失败率
    • 事务回滚率
    • 线程池活跃度

通过合理选择事务传播行为并遵循线程安全实践，可以在保证数据一致性的同时，构建高性能、高可用的并发应用系统。

http://www.lryc.cn/news/597465.html

相关文章：

  • 软件开发生命周期与模型解析：选择合适的开发方法
  • 什么是ARQ协议
  • 如何最简单、通俗地理解Python的numpy库？
  • C语言习题讲解-第五讲-循环编程练习等
  • Excel——设置打印的区域
  • CSS3文本阴影特效全攻略
  • 运营端账号管理设计指南：安全与效率的双重保障
  • 牛油果褐变的成因与食用安全
  • ElasticSearch基础数据管理详解
  • 同一个端口无法同时配置基于 server_name 的 HTTP（非加密）和 HTTPS（加密）
  • 数据科学与大数据技术和统计学有什么区别？​
  • [IMX][UBoot] 17.Linux 根文件系统
  • Elasticsearch Circuit Breaker 全面解析与最佳实践
  • MCU驱动AD5231BRUZ_10K
  • 【Elasticsearch】跨集群检索（Cross-Cluster Search）
  • 83、设置有人DTU设备USR-M100采集传感器数据，然后上传阿里云服务
  • now能减少mysql的压力吗
  • 旅游管理虚拟仿真实训室：重构实践教学新生态
  • 【数据库】国产数据库的新机遇：电科金仓以融合技术同步全球竞争
  • 云蝠智能 Voice Agent：重构企业语音交互，引领 AI 服务新范式
  • QGraphicsScene导出为PDF
  • SQL Server 数据类型的含义、特点及常见使用场景的详细说明
  • 【轨物洞见】光伏逆变器数据：分布式电站价值回归的“第一块多米诺骨牌”
  • Pycharm2025 安装教程 免费分享 没任何套路
  • PyCharm高效进阶指南：掌握专业开发技巧与最佳实践
  • Spring DeferredResult 实现长轮询
  • [HarmonyOS] HarmonyOS LiteOS-A 设备开发全流程指南
  • 清华大学层次化空间记忆助力具身导航！Mem4Nav：基于层次化空间认知长短期记忆系统的城市环境视觉语言导航
  • 本地部署 Stable Diffusion：零基础搭建 AI文生图模型
  • 仓颉兴趣组优秀项目-Ginger