面试官问我MySQL默认隔离级别，我直接甩给他这个带图的例子
面试官问我MySQL默认隔离级别，我这样回答让他眼前一亮
"能解释下MySQL默认的事务隔离级别吗？在实际项目中遇到过什么问题？"——这是Java后端面试中的高频考题。很多候选人会机械地背诵四种隔离级别的定义，但真正能结合业务场景讲清楚底层原理的却不多。今天我们就用一个电商库存管理的实战案例，带你穿透理论直击本质。
1. 为什么隔离级别是面试必考题？
事务隔离级别直接关系到系统的并发性能和数据一致性。想象一下双十一大促时，每秒数万次的库存扣减请求如果处理不当，轻则出现超卖，重则导致资金损失。MySQL默认采用**可重复读（REPEATABLE READ）**隔离级别，这既不是最高也不是最低的隔离层级，背后蕴含着数据库设计者对性能与一致性的权衡。
在Spring框架中，我们常用@Transactional注解管理事务。其隔离级别配置与MySQL的对应关系如下：
| Spring隔离级别常量 | MySQL等效级别 | 典型应用场景 |
|---|---|---|
| ISOLATION_READ_UNCOMMITTED | READ UNCOMMITTED | 实时监控系统（容忍脏读） |
| ISOLATION_READ_COMMITTED | READ COMMITTED | 银行转账（避免脏读） |
| ISOLATION_REPEATABLE_READ | REPEATABLE READ | 对账系统（保证多次读取一致） |
| ISOLATION_SERIALIZABLE | SERIALIZABLE | 金融结算（完全隔离） |
2. 图解可重复读的魔法与陷阱
让我们通过一个库存扣减的案例，用具体SQL演示隔离级别的影响。假设商品SKU-1001初始库存为10：
-- 事务A：查询库存 START TRANSACTION; SELECT stock FROM inventory WHERE sku = 'SKU-1001'; -- 返回10 -- 事务B：扣减库存 START TRANSACTION; UPDATE inventory SET stock = stock - 1 WHERE sku = 'SKU-1001'; COMMIT; -- 事务A再次查询 SELECT stock FROM inventory WHERE sku = 'SKU-1001'; -- 仍然返回10！ COMMIT;这就是可重复读的核心特性：事务内多次读取同一条记录时，结果始终保持一致。MySQL通过MVCC（多版本并发控制）机制实现这一点——事务启动时会创建数据快照，后续读取都基于这个快照版本。
但这种机制也埋下了幻读的隐患。看下面这个范围查询案例：
-- 事务A：查询低价商品 START TRANSACTION; SELECT * FROM products WHERE price < 100; -- 返回5条记录 -- 事务B：新增低价商品 START TRANSACTION; INSERT INTO products(name,price) VALUES('特价商品',99); COMMIT; -- 事务A再次查询 SELECT * FROM products WHERE price < 100; -- 仍然返回5条记录 COMMIT;注意：虽然可重复读能避免不可重复读，但对于范围查询可能出现幻读现象。这是面试时经常被追问的技术细节。
3. 四种隔离级别的实战对比
通过银行转账场景，我们直观比较不同级别的表现差异：
READ UNCOMMITTED（未提交读）
- 事务A读取到事务B未提交的转账金额
- 如果事务B最终回滚，事务A看到的就是"脏数据"
READ COMMITTED（提交读）
- 事务A只能看到事务B已提交的转账
- 但同一事务内两次查询可能结果不同（不可重复读）
REPEATABLE READ（可重复读）
- 事务A多次查询账户余额结果一致
- 但新增转账记录可能导致统计金额变化（幻读）
SERIALIZABLE（串行化）
- 完全禁止并发修改，性能代价最高
- 通过锁机制实现绝对隔离
下表总结了各隔离级别的问题表现：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 性能代价 |
|---|---|---|---|---|
| READ UNCOMMITTED | ✓ | ✓ | ✓ | 最低 |
| READ COMMITTED | × | ✓ | ✓ | 低 |
| REPEATABLE READ | × | × | ✓ | 中 |
| SERIALIZABLE | × | × | × | 最高 |
4. Spring事务中的最佳实践
在Java应用中，我们通常通过声明式事务管理隔离级别。以下是典型配置示例：
@Service public class OrderService { @Transactional(isolation = Isolation.REPEATABLE_READ) public void placeOrder(Order order) { // 检查库存 Inventory inventory = inventoryRepo.findBySku(order.getSku()); if(inventory.getStock() < order.getQuantity()) { throw new InsufficientStockException(); } // 扣减库存 inventoryRepo.reduceStock(order.getSku(), order.getQuantity()); // 创建订单 orderRepo.save(order); } }实际开发中还需要注意：
- 默认情况下Spring使用数据库的默认隔离级别（MySQL是可重复读）
- 高并发场景可结合
@Version乐观锁防止更新丢失 - 对一致性要求极高的操作可考虑
SELECT FOR UPDATE显式加锁
我曾在一个秒杀系统中遇到这样的坑：虽然使用了可重复读隔离级别，但由于没有处理幻读问题，导致库存统计出现偏差。后来通过以下方案解决：
-- 在事务开始时先锁定可能涉及的范围 SELECT * FROM inventory WHERE category = 'electronics' FOR UPDATE;这种主动锁定策略虽然会影响并发性能，但确保了数据的绝对准确性。技术选型永远是在一致性和性能之间寻找平衡点。