如何实现SERIALIZABLE隔离级别

在数据库里，SERIALIZABLE（可串行化）隔离级别的目标是：

并发执行的事务，效果等价于按某种顺序串行执行。

下面从实现原理、常见手段、优缺点和示例来说明。

一、SERIALIZABLE 的核心思想

SERIALIZABLE ≠ 真的串行执行，而是：

通过并发控制机制，让事务之间互不干扰，最终结果与某种串行执行一致。

二、主流实现方式

✅ 1. 两阶段锁（2PL，数据库最常用）

典型代表：MySQL InnoDB、Oracle、SQL Server

原理

• 事务在读/写数据前必须加锁
• 锁只有在事务提交或回滚时才释放

两个阶段：

1. 扩展阶段（Growing）：不断加锁
2. 收缩阶段（Shrinking）：只释放锁，不再加锁

锁的类型

示例（MySQL InnoDB）

SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
START TRANSACTION;

SELECT * FROM orders WHERE amount > 100;
-- 会对扫描到的数据加共享锁，阻塞其他事务修改

UPDATE orders SET amount = amount + 1 WHERE id = 1;
COMMIT;

✅ 优点：

• 严格保证可串行化
• 实现成熟、稳定

❌ 缺点：

• 锁冲突多
• 并发性能差
• 容易死锁

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

典型代表：PostgreSQL SERIALIZABLE

原理

• 使用 快照读（Snapshot）
• 事务不阻塞读，也不被读阻塞
• 提交时检测是否满足可串行化

PostgreSQL 的做法（SSI）

Serializable Snapshot Isolation（SSI）

• 事务基于快照执行
• 记录事务之间的 读写依赖
• 提交时检测是否存在 不可串行化的依赖环
• 如果发现冲突 → 回滚事务

BEGIN ISOLATION LEVEL SERIALIZABLE;

SELECT * FROM account WHERE id = 1;
UPDATE account SET balance = balance - 100 WHERE id = 1;

COMMIT;

✅ 优点：

• 读不阻塞写
• 并发性能优于 2PL

❌ 缺点：

• 需要事务重试机制
• 可能发生“假阳性”回滚

✅ 3. 完全串行执行（纯串行）

典型代表：单线程数据库、某些内存数据库

• 所有事务排队执行
• 根本不存在并发

✅ 优点：

• 绝对安全
• 实现简单

❌ 缺点：

• 性能极低
• 几乎只用于教学或特殊场景

三、三种方式对比

四、SERIALIZABLE 能解决哪些问题？

注：

• MySQL 的 REPEATABLE READ 用 Next-Key Lock 也能防止幻读
• 但 写偏斜问题只能 SERIALIZABLE 保证

五、使用建议

✅ 适合场景

• 金融、库存、强一致性系统
• 业务规则复杂、不能容忍并发异常

❌ 不适合场景

• 高并发、简单读写
• 能接受最终一致性的业务

六、一句话总结

SERIALIZABLE 的实现方式主要有：

• 严格加锁（2PL）
• MVCC + 提交时冲突检测（SSI）
• 或完全串行执行

代价是：
一致性最强，但并发性能最差。

如果你愿意，我可以：

• 用 PostgreSQL vs MySQL 对比 SERIALIZABLE
• 画一张 事务依赖图 解释 SSI
• 给你一个 写偏斜的真实业务案例