为什么需要SERIALIZABLE可串行化

在数据库和并发系统中，SERIALIZABLE（可串行化） 是最高的隔离级别，它的存在主要是为了解决并发事务带来的数据不一致问题，并在某些关键场景下保证“结果正确”。

下面从“为什么需要”的角度来说明。

一、并发会产生什么问题？

如果多个事务同时读写数据，而没有足够强的隔离，会出现：

1. 脏读（Dirty Read）
   • 读到别的事务还没提交的数据
2. 不可重复读（Non-repeatable Read）
   • 同一事务内，两次读同一数据，结果不一样
3. 幻读（Phantom Read）
   • 同一查询条件，两次查出来的“行数”不一样

这些问题在普通业务里可能只是小bug，但在钱、库存、权限、合同等场景里就是严重事故。

二、为什么需要 SERIALIZABLE？

1. 保证“像串行执行一样安全”

SERIALIZABLE 的核心目标是：

多个并发事务的执行结果，必须等价于某种“一个接一个串行执行”的结果

也就是说：

• 即使数据库内部并发执行
• 对外部来看，就像没有并发一样

这在以下场景是必须的：

• 银行转账
• 库存扣减
• 票务系统
• 财务报表
• 审计类系统

2. 防止“逻辑错误”，而不仅仅是“读错”

举个例子（没有 SERIALIZABLE）：

事务A：查余额 = 100
事务B：查余额 = 100
事务A：扣50，写50
事务B：扣80，写20

最终余额是 20，但：

• 两个事务都“以为”自己看到的是 100
• 实际已经超支

SERIALIZABLE 会阻止这种交叉执行，保证一致性。

3. 避免“业务规则被并发破坏”

很多业务规则不是单条 SQL 能表达的，例如：

• “同一用户不能同时下两笔冲突订单”
• “总人数不能超过上限”
• “状态机只能按固定顺序变更”

这些规则依赖：

• 读 → 判断 → 写

SERIALIZABLE 能保证这一步不会被别的事务“插队”。

4. 减少“应用层自己处理并发”的复杂度

如果没有 SERIALIZABLE：

• 应用要加锁
• 要重试
• 要判断版本号
• 要处理各种边界情况

而 SERIALIZABLE：

• 把一致性责任交给数据库
• 开发更简单、错误更少

三、那为什么不全用 SERIALIZABLE？

因为代价高：

• 锁更多
• 并发度下降
• 容易死锁
• 吞吐量降低

所以一般原则：

• 关键一致性路径：用 SERIALIZABLE
• 普通查询：用 READ COMMITTED / REPEATABLE READ

四、一句话总结

SERIALIZABLE 的存在，是为了在并发环境下，依然保证数据结果“绝对正确、像串行一样可靠”。

如果你愿意，我也可以：

• 用具体 SQL 示例演示问题
• 对比 MySQL / PostgreSQL 的实现差异
• 讲什么时候“其实不需要 SERIALIZABLE”