数据库SERIALIZABLE可串行化如何生效

在数据库中，SERIALIZABLE（可串行化） 是事务隔离级别中最严格的一级，目的是让并发事务的执行结果等价于某种串行执行顺序。下面从“它如何生效”的角度系统说明。

一、SERIALIZABLE 的目标

多个事务并发执行，最终结果必须与“按某种顺序一个一个执行”的结果一致。

它要解决的是：

• 脏读（Dirty Read）
• 不可重复读（Non-repeatable Read）
• 幻读（Phantom Read）

二、SERIALIZABLE 如何“生效”（核心机制）

不同数据库实现方式不同，但本质机制有三类：

1. 锁机制（Locking，最经典）

典型代表

• MySQL InnoDB
• SQL Server（默认实现之一）

生效方式

• 读操作：加 共享锁（S locks）
• 写操作：加 排他锁（X locks）
• 锁通常持续到 事务结束（commit / rollback）

示例：

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
SELECT * FROM account WHERE id = 1;
-- 对读取的数据加共享锁
UPDATE account SET balance = balance - 100 WHERE id = 1;
COMMIT;

特点：

• 其他事务不能修改被读的数据
• 其他事务不能插入“满足条件的新行”（防幻读）

✅ 优点：实现直观
❌ 缺点：并发低，容易锁等待、死锁

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

典型代表

• PostgreSQL（SERIALIZABLE 实际实现）
• Oracle（类似机制）

生效方式

• 事务开始时获取一个 快照（Snapshot）
• 读不阻塞写，写不阻塞读
• 在 提交时检测冲突
  • 若两个事务“读写冲突”
  • 其中一个被回滚（serialization failure）

示例（PostgreSQL）：

BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT * FROM orders WHERE user_id = 1;
INSERT INTO orders(...) VALUES (...);
COMMIT;
-- 若与其他事务冲突，会报：
-- ERROR: could not serialize access due to concurrent update

✅ 优点：高并发
❌ 缺点：需要应用层处理重试

3. 谓词锁 / 区间锁（防止幻读）

关键问题

如何防止“别的事务插入符合条件的新数据”？

解决方案：

• Next-Key Lock（MySQL）
  • 锁住“索引记录 + 区间”
• Predicate Lock（理论 / PostgreSQL 内部）

示例：

SELECT * FROM user WHERE age > 20;

SERIALIZABLE 下可能锁住：

• age > 20 的整个区间
• 防止插入 age = 25 的新用户

三、SERIALIZABLE 的“生效条件”

要让 SERIALIZABLE 真正生效，必须注意：

1. 数据库支持

• MySQL：✅（InnoDB）
• PostgreSQL：✅
• Oracle：✅（但实现不同于标准）

2. 设置方式正确

-- 会话级
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- 或事务级
BEGIN ISOLATION LEVEL SERIALIZABLE;

3. 事务边界明确

• 必须 BEGIN / COMMIT
• 自动提交模式（autocommit=1）下无意义

四、SERIALIZABLE 不等于“真的串行”

很重要的一点：

SERIALIZABLE 保证的是 结果等价，不是执行顺序串行。

数据库仍可能：

• 并发执行
• 使用快照
• 在提交阶段解决冲突

五、适用场景

适合：

• 资金转账
• 库存扣减
• 强一致性要求的业务逻辑

不适合：

• 高并发读多写少
• 对性能极度敏感的系统

六、一句话总结

SERIALIZABLE 通过“锁 / MVCC 冲突检测 / 谓词锁”等机制，确保并发事务的结果等价于某种串行执行顺序，从而保证最强的一致性。

如果你愿意，我可以：

• 用 具体例子 演示幻读如何被 SERIALIZABLE 阻止
• 对比 MySQL vs PostgreSQL 的实现差异
• 讲 什么时候不该用 SERIALIZABLE