并发事务那点事儿：面试常考的坑与解法

并发事务会引发哪些问题?

我的回答：

并发事务引发的问题，主要有这么几个：

• 脏读：就是一个事务，读取到了另一个事务还没有提交的数据。
• 不可重复读：指的是一个事务里多次读取的数据不一致，是受到其它事务的update操作干扰了。
• 幻读：指的是一个事务按照条件查询数据时，没有对应的行，但是插入时，又发现这行数据已经存在了好像出现了幻觉。

如何解决这些问题呢?

我的回答：

出现事务并发问题的根本原因是：事务并发时的隔离不彻底，导致事务之间互相干扰了。

数据库中提供了不同的隔离级别来解决这些问题， 分别有以下几种：

说明	隔离级别	脏读	不可重复读	幻读
最低隔离级别：性能最好，最不安全	READ UNCOMMITED（RU）	有	有	有
Oracle默认这个级别	READ COMMITTED（RC）	×	有	有
MySQL默认这个级别	REPEATABLE READ（RR）	×	×	有
最高隔离级别：最安全，性能最差	SERIALIZABLE（串行化）	×	×	×

而在MySQL数据库中，默认的隔离级别是 REPEATABLE READ（可重复读）。

那为什么没有用SERIALIZABLE(串行化) 这种隔离级别呢?

我的回答：

隔离级别不是越高越好。因为隔离级别高了，确实可以解决并发事务引发的问题，但是隔离级别越高，性能也越低。

后端面试聊数据库，十有八九绕不开并发事务。今天用大白话拆解下，多事务同时运行会出哪些问题，以及怎么落地解决。

觉得有用的话，点赞收藏就是对硬核干货最好的认可～谢谢啦~

一、并发事务高频面试问题全景透视

（一）面试官必问：并发事务典型问题分类

在高并发场景下，数据库事务可能引发三类经典数据不一致问题，这些问题是后端开发面试中考察事务理解的核心考点：

1. 脏读（Dirty Read） ：事务 A 读取到事务 B 未提交的修改数据，若事务 B 回滚，事务 A 获取的脏数据会导致业务逻辑错误。例如订单系统中，用户 A 的余额修改事务未提交时，用户 B 查询到临时变更的余额并进行消费。

2. 不可重复读（Non - Repeatable Read） ：同一事务内多次读取同一数据结果不一致，主要由其他事务的更新（UPDATE）操作引发。典型场景：财务系统中，统计事务在执行过程中，其他事务修改了账单金额，导致多次统计结果不同。

3. 幻读（Phantom Read） ：事务执行过程中，因其他事务插入（INSERT）数据，导致相同查询条件返回的结果集行数变化。如库存管理中，批量更新库存前查询符合条件的商品数量为 100，更新时实际操作 105 条数据，多出的 5 条即为幻读数据。

（二）问题本质：并发读写引发的数据不一致根源

三大问题的本质是事务隔离性不足，当多个事务对同一数据域进行交叉操作时，数据库未能有效控制访问顺序。根本原因包括：

1. 锁机制缺陷：未正确使用锁或锁粒度不当，导致读操作与写操作交叉执行

2. 隔离级别配置不合理：未根据业务场景选择合适的事务隔离级别

3. 多版本控制缺失：缺乏数据版本管理机制，无法保证读操作的一致性视图

二、分场景解决方案深度拆解

（一）事务隔离级别：从 SQL 标准到引擎实现

SQL 标准定义了四种事务隔离级别，数据库引擎通过不同的锁和并发控制机制实现这些级别，为事务提供不同程度的隔离性：

1. 读未提交（Read Uncommitted，RU） ：事务可读取其他事务未提交的数据，是最低隔离级别，并发性能最高但不保证数据一致性，可能出现脏读、不可重复读和幻读。

2. 读已提交（Read Committed，RC） ：事务只能读取已提交的数据，避免了脏读，但同一事务内多次读取可能因其他事务提交更新而产生不可重复读和幻读问题。多数数据库默认此级别，如 Oracle 和 SQL Server。

3. 可重复读（Repeatable Read，RR） ：事务执行期间多次读取同一数据结果一致，通过 MVCC 实现一致性读视图，避免脏读和不可重复读，但仍可能出现幻读。MySQL InnoDB 引擎默认使用 RR，并通过间隙锁（Gap Lock）在一定程度上解决幻读问题 。

4. 串行化（Serializable） ：最高隔离级别，事务串行执行，完全避免并发问题，但性能最低，因为它使用表级锁或范围锁，阻止并发事务对同一数据的读写操作。

（二）锁机制：从悲观锁到乐观锁的选型策略

锁机制是控制并发事务访问共享资源的关键手段，通过对数据加锁来保证在同一时刻只有一个事务能修改数据，分为悲观锁和乐观锁：

1. 悲观锁（Pessimistic Lock） ：假定事务处理过程中会发生冲突，在操作数据前获取锁，直到事务结束才释放。悲观锁分为共享锁（Shared Lock，S 锁）和排他锁（Exclusive Lock，X 锁）：

• • 共享锁（S 锁） ：允许事务对数据进行并发读操作，但阻止写操作。多个事务可以同时持有同一数据的共享锁，保证数据一致性读取。

• • 排他锁（X 锁） ：独占数据访问权，阻止其他事务对数据的读和写操作。常用于更新和删除操作，确保数据修改的原子性。

2. 乐观锁（Optimistic Lock） ：假设事务间冲突较少，在提交数据时检查是否有其他事务修改了数据。乐观锁基于版本号（Version Number）或 CAS（Compare-And-Swap）机制实现：

• • 版本号机制：数据库表中增加版本号字段，事务读取数据时获取版本号，更新时比较当前版本号与读取时的版本号是否一致，一致则更新并递增版本号，否则回滚事务。

• • CAS 机制：在内存中比较预期值与当前值是否相同，相同则更新为新值，否则重试或回滚事务。适用于读多写少的场景，如电商商品浏览、新闻资讯展示等，可提高并发性能，但需处理更新冲突。

（三）MVCC：多版本并发控制的核心实现原理

MVCC（Multi-Version Concurrency Control）是一种高并发控制机制，通过保存数据的多个版本，实现读写操作的非阻塞执行，提升数据库并发性能。以 MySQL InnoDB 引擎为例，MVCC 主要通过以下机制实现：

1. 隐藏字段与版本链：InnoDB 为每行数据添加隐藏字段，包括 DB_TRX_ID（事务 ID）和 DB_ROLL_PTR（回滚指针）。每次数据修改时，生成新版本并记录到 Undo Log 中，通过回滚指针形成版本链，保存数据的历史状态。

2. 读视图（Read View） ：事务启动时，InnoDB 生成一个读视图，记录当前活跃事务 ID 集合。读操作根据读视图和版本链判断数据版本的可见性，决定读取哪个版本的数据。

3. 可见性判断规则：读操作时，比较数据的 DB_TRX_ID 与读视图中的事务 ID 范围，确定数据是否可见。如果 DB_TRX_ID 小于读视图中最小事务 ID，表示数据已提交且可见；如果 DB_TRX_ID 大于等于读视图中最大事务 ID，表示数据是未来事务修改的，不可见；如果 DB_TRX_ID 在活跃事务 ID 集合中，表示事务未提交，数据不可见 。

三、面试加分项：进阶问题与最佳实践

（一）面试官深挖：幻读与不可重复读的本质区别

在面试中，深入理解幻读与不可重复读的差异能体现对事务问题的深度认知，这两者虽然都涉及同一事务内多次读取结果不一致，但在多个维度上存在本质区别：

1. 维度差异：不可重复读聚焦于单行数据，强调同一数据行被其他事务更新（UPDATE）导致多次读取内容不同；而幻读关注的是结果集，由于其他事务的插入（INSERT）操作，使得相同查询条件下返回的记录行数发生变化。例如，在用户信息查询事务中，不可重复读表现为两次读取同一用户的年龄字段值不同；幻读则是第一次查询 10 个用户，第二次查询却返回 11 个用户。

2. 隔离级别影响：在可重复读（RR）隔离级别下，数据库通过 MVCC 机制保证了同一事务内对单行数据读取的一致性，解决了不可重复读问题，但对于结果集的新增数据无法完全避免，仍可能出现幻读 。如 MySQL InnoDB 引擎在 RR 级别下，需要间隙锁（Gap Lock）辅助才能进一步解决幻读问题。

3. 业务影响：不可重复读主要影响对单行数据依赖的业务逻辑，如基于用户余额进行扣款操作；幻读对涉及批量操作的业务影响更大，可能导致操作范围扩大或缩小，如电商促销活动中批量更新商品价格，由于幻读可能多更新或漏更新部分商品，引发库存超卖或促销成本增加等风险。

（二）性能优化：隔离级别与锁策略的平衡艺术

在解决并发事务问题时，不能只关注数据一致性，还需兼顾系统性能，通过优化隔离级别与锁策略来实现两者的平衡：

1. 优先选择低隔离级别：在满足业务一致性要求的前提下，优先考虑读已提交（RC）隔离级别，它在大多数场景下已能保证基本的数据一致性，且性能优于可重复读（RR）和串行化级别。RR 级别虽能避免不可重复读，但间隙锁的使用会增加锁争用和事务等待时间，降低并发性能，因此选择 RR 级别时需充分评估业务对性能的影响。

2. 缩小事务范围：将大事务拆分为多个小事务，特别是对高并发操作的事务，减少锁的持有时间。例如，在电商订单处理中，将订单创建、库存扣减和支付操作拆分成独立事务，通过消息队列或分布式事务框架保证最终一致性，避免长事务导致的锁资源长时间占用。

3. 索引优化：确保加锁语句使用索引，避免全表扫描导致锁升级为表锁。例如，在 UPDATE 操作中，若条件字段有索引，数据库可使用行锁或间隙锁，大幅提高并发性能；若没有索引，则可能对整个表加锁，阻塞其他事务对表的读写操作。

4. 异步补偿机制：对于一致性要求不高的业务场景，结合最终一致性方案，如利用消息队列实现异步补偿机制。以订单状态更新为例，当订单创建成功后，通过消息队列异步通知库存系统扣减库存，若扣减失败，消息队列可进行重试，保证最终库存数据的准确性 。

（三）面试应答模板：问题分析到方案落地的完整链路

在面试中回答并发事务问题时，采用结构化的应答方式能全面展示分析问题和解决问题的能力。当被问及 “如何解决并发事务问题” 时，可遵循以下应答结构：

1. 问题识别：首先明确具体问题类型，判断是脏读、不可重复读还是幻读，结合业务场景详细分析问题产生的原因和可能带来的影响。例如，在电商库存管理中，若出现超卖问题，经分析是由于脏读导致事务读取到未提交的库存修改数据，可能引发客户投诉和商家损失。

2. 方案选择：根据业务对一致性和性能的要求，选择合适的解决方案，可从基础方案、进阶方案和工程方案三个层面阐述：

• • 基础方案：根据一致性要求选择事务隔离级别，如订单查询业务对实时性要求较高，数据一致性要求相对较低，可选择读已提交（RC）级别；财务统计业务对数据准确性要求极高，需选择可重复读（RR）或串行化级别。

• • 进阶方案：结合锁机制（如 SELECT FOR UPDATE 语句实现悲观锁）或 MVCC 特性（利用版本号控制实现乐观锁）进一步保证数据一致性。例如，在秒杀业务中，使用 SELECT FOR UPDATE 锁定商品库存记录，防止超卖；在读多写少的新闻资讯系统中，利用 MVCC 的版本号机制实现乐观锁，提高并发性能。

• • 工程方案：考虑数据库引擎特性（如 InnoDB 的间隙锁机制）和业务补偿机制（如消息队列重试、定时任务对账），确保方案在实际工程环境中的可行性和稳定性。例如，在分布式电商系统中，利用消息队列实现订单创建、库存扣减和支付的异步处理，结合定时任务对账保证数据一致性。

3. 权衡取舍：说明不同方案的性能影响和适用场景，体现对技术选型的综合考量。例如，串行化隔离级别虽然能完全避免并发事务问题，但会严重降低系统吞吐量，适用于对一致性要求极高、并发量较低的场景；乐观锁虽能提高并发性能，但存在更新冲突导致事务回滚的风险，适用于读多写少的场景 。

四、总结：构建事务管理的技术知识体系

掌握并发事务问题需形成 “问题场景 - 技术原理 - 工程实践” 的完整认知链：理解三大问题的本质特征与发生条件；精通隔离级别、锁机制、MVCC 的技术实现细节；能够根据业务场景选择最优方案，平衡一致性与性能；熟悉主流数据库（MySQL/Oracle）的事务处理特性。这些知识不仅是面试考察重点，更是分布式系统设计的核心基础。在实际项目中，需通过压力测试验证事务方案的有效性，结合监控系统实时追踪锁竞争与事务超时情况，确保高并发场景下的数据一致性与系统稳定性。