什么业务用SERIALIZABLE可串行化

在数据库中，SERIALIZABLE（可串行化） 是事务隔离级别中最严格的一级，它保证并发事务的执行效果等同于按某种顺序串行执行，从而避免脏读、不可重复读和幻读。

一般来说，只有当业务逻辑对数据一致性和正确性要求极高、且并发冲突代价很高时，才考虑使用 SERIALIZABLE。下面按“典型业务场景”来说明哪些业务适合用它。

一、典型适用 SERIALIZABLE 的业务

1. 金融核心交易类

典型业务：

• 银行转账
• 账户余额扣减 / 充值
• 清算、结算

原因：

• 不允许任何中间状态被看到
• 不能出现“重复扣款”“余额为负”“并发修改账户”

示例：

-- 转账
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
UPDATE account SET balance = balance - 100 WHERE id = 1;
UPDATE account SET balance = balance + 100 WHERE id = 2;
COMMIT;

2. 库存 / 名额 / 票数类业务（强一致性）

典型业务：

• 秒杀
• 火车票、机票购买
• 演唱会门票
• 考试名额、抽奖名额

原因：

• 不能超卖
• 不能两个事务同时“看到有库存”并都成功

示例：

BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT stock FROM item WHERE id = 10;
-- 应用判断 stock > 0
UPDATE item SET stock = stock - 1 WHERE id = 10;
COMMIT;

注：高并发场景下，SERIALIZABLE 可能导致大量锁等待，常配合“乐观锁 / 分布式锁”使用。

3. 财务对账 / 报表生成

典型业务：

• 日终对账
• 总账计算
• 税务报表
• 审计数据导出

原因：

• 数据必须“某一时刻完全一致”
• 不能读到一半更新后的数据

4. 订单状态机（关键状态变更）

典型业务：

• 订单支付成功
• 退款
• 取消订单

原因：

• 状态只能单向流转（待支付 → 已支付 → 已发货）
• 防止并发导致“重复支付”“重复退款”

5. 分布式系统中的“全局一致读”

典型业务：

• 跨服务事务
• 配置中心读取
• 全局序列号生成

原因：

• 需要看到“完全一致的快照”

二、不太适合 SERIALIZABLE 的业务

这些通常用：

• READ COMMITTED
• REPEATABLE READ
• 乐观锁（version）

三、使用 SERIALIZABLE 的代价

• 锁多（行锁、间隙锁、表锁）
• 容易：
  • 锁等待
  • 死锁
  • 吞吐量下降
• 在 MySQL / PostgreSQL 中表现不同

四、一句话总结

SERIALIZABLE 适合“错一次代价极大”的业务：钱、库存、对账、关键状态变更。

如果你愿意，我可以：

• 用 MySQL / PostgreSQL 举例
• 帮你判断 你的业务要不要 SERIALIZABLE
• 讲 SERIALIZABLE vs 乐观锁 怎么选