数据库SERIALIZABLE可串行化有何用

在数据库中，SERIALIZABLE（可串行化） 是事务隔离级别（Isolation Level）中的最高级别，它的核心作用是保证并发事务的执行结果，等同于某种“串行执行”的结果，从而彻底避免并发导致的数据不一致问题。

下面从“有什么用、解决什么问题、代价是什么”三个角度说明。

一、SERIALIZABLE 有什么用？

一句话：防止所有并发异常，保证数据绝对逻辑正确。

在 SERIALIZABLE 下，数据库保证：

多个事务并发执行的结果，一定和“某个顺序一个一个执行”的结果一致。

这意味着它可以防止：

• 脏读（Dirty Read）
• 不可重复读（Non-repeatable Read）
• 幻读（Phantom Read）
• 写偏斜（Write Skew）
• 丢失更新（Lost Update）

（比 REPEATABLE READ 更强，尤其能避免幻读和写偏斜）

二、它解决了哪些典型问题？

1. 防止幻读

事务A：统计账户余额 > 100 的人数
事务B：插入一个余额 200 的新账户

在较低隔离级别下，A 可能两次统计结果不一致。
SERIALIZABLE 保证：B 的插入“看起来”是在 A 之后或之前完成的，不会“凭空出现”。

2. 防止写偏斜（Write Skew）

典型例子：

• 医生值班系统：规则是“至少一人值班”
• 两个医生同时请假

在低隔离级别下：

• A 看到 B 在
• B 看到 A 在
• 两人都请假 → 系统违规

SERIALIZABLE 能阻止这种逻辑冲突。

3. 金融、库存、票务等关键场景

如：

• 银行转账
• 库存扣减
• 票数售卖

这些场景不允许任何并发误差，SERIALIZABLE 是最安全的选择。

三、它是怎么做到的？

数据库通常手段：

• 锁（行锁、间隙锁、范围锁）
• 多版本 + 冲突检测（如 Serializable Snapshot Isolation, SSI）
• 冲突时回滚事务（报错：serialization failure）

四、代价是什么？（很重要）

SERIALIZABLE 不是“免费的安全”：

• ✅ 数据最安全
• ❌ 并发性能最低
• ❌ 容易锁等待、死锁
• ❌ 事务更容易失败重试

所以在生产中：

• 关键操作：用 SERIALIZABLE
• 普通查询：用 READ COMMITTED / REPEATABLE READ

五、什么时候该用？

✅ 适合：

• 强一致性业务
• 并发写冲突明显
• 不能接受任何逻辑错误

❌ 不适合：

• 高并发只读
• 对性能极度敏感
• 可以接受最终一致

一句话总结

SERIALIZABLE 的作用是：用性能和并发为代价，换取“像单线程一样安全”的数据库正确性。

如果你愿意，我也可以对比 MySQL / PostgreSQL 中 SERIALIZABLE 的具体实现差异。