数据库SERIALIZABLE可串行化原理啥

在数据库里，SERIALIZABLE（可串行化） 是事务隔离级别中最严格的一级，目标是：让并发执行的事务，在结果上等价于某种“一个接一个串行执行”的顺序。

下面从「要解决的问题 → 实现原理 → 常见实现方式」讲清楚。

一、为什么需要 SERIALIZABLE

多个事务并发执行时，如果不加控制，会出现：

• 脏读
• 不可重复读
• 幻读
• 写偏斜（write skew）

SERIALIZABLE 要保证：

无论你怎么并发跑，最终结果都像事务被“排队依次执行”一样 正确且一致

注意：
可串行化 ≠ 真的一个一个跑，而是“结果等价”。

二、核心原理：冲突可串行化（Conflict Serializability）

数据库通常通过**事务之间的“冲突操作”**来判断是否可串行化。

1. 什么是冲突操作

两个操作冲突，当且仅当：

• 属于不同事务
• 操作同一数据项
• 至少有一个是写操作

典型冲突：

• 读 ↔ 写（RW）
• 写 ↔ 读（WR）
• 写 ↔ 写（WW）

2. 冲突等价 & 可串行化调度

如果一个并发执行顺序，可以通过交换不冲突的操作，变成一个“事务首尾不交叉”的串行顺序，那它就是冲突可串行化的。

示例：

T1: R(A) W(A)
T2: R(A) W(A)

并发：
R1(A) R2(A) W1(A) W2(A)
→ 可化为 T1 然后 T2
→ 可串行化

三、数据库如何实现 SERIALIZABLE

不同数据库实现方式不同，常见有 3 类：

1. 两阶段锁（2PL，最经典）

原理

• 加锁阶段：事务只能加锁，不能释放
• 解锁阶段：事务只能释放锁，不能再加

锁类型

• 共享锁（S，读）
• 排他锁（X，写）

效果

• 读写互斥
• 写写互斥
• 防止幻读（配合间隙锁 / 范围锁）

✅ 优点：严格正确
❌ 缺点：锁多、易死锁、吞吐低

MySQL InnoDB 的 SERIALIZABLE 基本靠 2PL + 间隙锁

2. 多版本并发控制 + 冲突检测（MVCC + Serialization）

如 PostgreSQL（真正 SERIALIZABLE）：

• 每个事务有快照
• 读不阻塞写
• 提交时检测：是否发生写偏斜

检测方式

• 依赖图（dependency graph）
• 如果发现环 → 回滚一个事务

✅ 读性能好
❌ 写冲突时要回滚

3. 时间戳 / 乐观并发控制（OCC）

• 给事务分配时间戳
• 执行时不加锁
• 提交时检查是否“时间顺序被打破”
• 若违反 → 回滚

适合读多写少场景。

四、SERIALIZABLE 能防止什么

⚠️ 注意：

• MySQL 的 REPEATABLE READ 用 MVCC，但不防写偏斜
• 只有 SERIALIZABLE 才严格防

五、一句话总结

SERIALIZABLE 的原理是：通过锁 / 版本 / 冲突检测，保证并发事务的执行结果，等价于某个串行执行顺序，从而绝对不会出现一致性问题。

如果你愿意，我也可以：

• 用具体 SQL 例子演示写偏斜
• 对比 MySQL vs PostgreSQL 的 SERIALIZABLE
• 画事务冲突图帮你理解