数据库事务隔离级别怎么选

选数据库事务隔离级别，核心是在数据一致性和并发性能之间做权衡。没有“最好”，只有“最适合业务场景”。

下面用结论先行 + 对比 + 场景 + 选型建议的方式讲清楚。

一、先给结论（快速选型）

✅ 90% 系统的推荐起点：

Read Committed（RC）

如果：

• 使用 MySQL + InnoDB
• 业务不是金融级强一致
• 并发量中等或偏高

✅ 金融、账务、库存扣减等强一致场景：

Repeatable Read（RR）或 Serializable

✅ 几乎不推荐直接用 Serializable，除非极端场景

二、四种标准隔离级别速览

⚠️ MySQL InnoDB 的 RR 通过 Next-Key Lock 基本解决了幻读

三、各级别通俗解释

1️⃣ Read Uncommitted（读未提交）

• 能读到别人还没提交的数据
• 一旦回滚，数据就是错的（脏读）

❌ 生产环境几乎不用

2️⃣ Read Committed（读已提交）✅ 最常用

• 只能读到已经提交的数据
• 同一事务内，两次查询结果可能不一样（不可重复读）

✅ 适合：

• 普通业务系统
• Web 应用
• 微服务

✅ 并发好、问题少

3️⃣ Repeatable Read（可重复读）

• 同一事务中，多次读取结果一致
• 适合对“数据快照一致性”要求高的场景

✅ 适合：

• 财务计算
• 报表
• 批量对账

⚠️ 注意：

• 可能有间隙锁
• 并发略低于 RC

4️⃣ Serializable（串行化）

• 事务完全串行执行
• 性能最差

❌ 一般不用
✅ 仅用于：

• 数据极度敏感
• 并发极低
• 一致性要求绝对优先

四、MySQL 的特殊点（非常重要）

✅ InnoDB 默认隔离级别是：Repeatable Read

但：

• 通过 MVCC + Next-Key Lock
• 基本避免了幻读

所以：

MySQL 的 RR ≠ 标准 SQL 的 RR

五、怎么选？一张决策表

六、实战建议（非常重要）

✅ 1. 别迷信“越高越好”

高隔离级别 ≠ 更安全
可能带来 锁等待、死锁、性能下降

✅ 2. 事务要“短”

无论什么隔离级别：

• 事务越短越好
• 不要在一次事务里：
  • 调接口
  • 写日志
  • 做复杂计算

✅ 3. 如果需要“强一致”，优先用设计解决

而不是盲目提高隔离级别：

• 乐观锁（version）
• 悲观锁（SELECT … FOR UPDATE）
• 幂等 + 补偿
• 业务状态机

七、一句话总结

默认用 Read Committed，一致性要求高用 Repeatable Read，极端情况才用 Serializable。

如果你愿意，可以告诉我：

• 用的是 MySQL / PostgreSQL / Oracle
• 业务类型（订单、支付、库存、报表）

我可以直接给你最合适的具体配置和示例。