温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

SERIALIZABLE可串行化与RC有何别

发布时间:2026-11-05 14:10:04 来源:亿速云 阅读:93 作者:小樊 栏目:数据库

在数据库事务隔离级别中,SERIALIZABLE(可串行化) 和 RC(Read Committed,读已提交) 是两种差异非常大的隔离级别。下面从多个维度对比它们的区别。


1. 基本定义

  • RC(Read Committed)

    • 事务只能看到已经提交的数据
    • 每次查询都会读取最新已提交的数据
    • 避免了脏读,但可能出现不可重复读和幻读
  • SERIALIZABLE(可串行化)

    • 事务的执行效果等价于某种串行执行顺序
    • 最强隔离级别
    • 避免脏读、不可重复读、幻读

2. 能避免的并发问题

并发问题 RC SERIALIZABLE
脏读 ❌ 避免 ✅ 避免
不可重复读 ❌ 可能出现 ✅ 避免
幻读 ❌ 可能出现 ✅ 避免
写偏斜(write skew) ❌ 可能出现 ✅ 避免

3. 读行为差异

RC

  • 同一事务内:
    • 第一次读:value = 10
    • 另一事务提交修改为 20
    • 再次读:value = 20
  • 读的是最新已提交快照

SERIALIZABLE

  • 同一事务内:
    • 第一次读:value = 10
    • 即使其他事务提交修改
    • 再次读仍是:value = 10
  • 表现得像事务开始时就“冻结”了数据库状态

4. 实现机制差异

RC 常见实现

  • 语句级快照(MVCC)
  • 或加短期共享锁

SERIALIZABLE 常见实现

  • 严格两阶段锁(2PL)
  • 或 MVCC + 序列化冲突检测(如 PostgreSQL)
  • 或范围锁 / 间隙锁(如 MySQL InnoDB)

5. 并发性能与锁冲突

项目 RC SERIALIZABLE
并发度 高 低
锁持有时间 短 长
死锁概率 低 高
吞吐量 高 低

6. 典型使用场景

  • RC

    • 大多数业务系统
    • 对一致性要求不极端
    • 如订单查询、用户资料
  • SERIALIZABLE

    • 金融、库存、票务
    • 强一致性要求
    • 如“余额扣减 + 流水写入”

7. 简单示例对比

RC 下(问题)

T1: 读库存 = 10
T2: 扣库存并提交 = 9
T1: 再读库存 = 9(不一致)

SERIALIZABLE 下

T1: 读库存 = 10
T2: 想改库存 → 被阻塞或失败
T1: 提交后 T2 才能继续

总结一句话

RC 保证“不看脏数据”,SERIALIZABLE 保证“像一个人依次执行一样安全”。

如果你用的是 MySQL / PostgreSQL / Oracle,我也可以结合具体数据库讲实现差异。

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI
助
手