为何要使用低于serializable的事务隔离级别？serializable读余额总和有何问题

为什么要使用低于Serializable的隔离级别？ #

Serializable作为SQL标准定义的最高隔离级别，虽然能完全避免脏读、不可重复读、幻读三类数据一致性问题，但生产环境极少全量使用，核心原因如下：

• 性能差距显著：传统基于锁实现的Serializable需要为事务访问的所有数据加事务级持有的锁，范围查询时还要加间隙锁防止幻读，会导致大量并发请求阻塞，吞吐量通常只有读提交（RC）、可重复读（RR）等低隔离级别的1/10甚至更低，完全无法满足高并发OLTP系统的性能要求。就算是PostgreSQL这类使用SSI（可序列化快照隔离）实现的数据库，额外的序列化冲突检测逻辑也会带来不小的性能开销，表现依然不如低隔离级别。
• 业务场景不需要绝对一致性：绝大多数业务场景都允许短暂的数据不一致，比如前端的商品库存展示、非实时的运营统计、用户的历史消费记录查询等，短时间的偏差不会影响核心业务逻辑，牺牲极弱的一致性换取数十倍的性能提升是更合理的选型。
• 运维和适配成本更低：Serializable隔离级别下事务冲突、死锁的发生概率远高于低隔离级别，业务侧需要开发大量的事务重试逻辑，运维侧也要额外处理大量事务超时、回滚带来的问题，非强一致核心场景完全不需要投入这部分成本。

两个使用Serializable隔离级别的用户同时读取账户余额总和，会出现什么问题？ #

分两种情况判断：

• 若两个事务仅做纯读操作，没有后续的余额修改动作：不存在任何一致性问题，两个用户都能拿到准确的余额总和。基于锁的Serializable实现中，两个事务持有的都是共享读锁，互相不阻塞；基于SSI的实现中读操作完全不加锁，连阻塞都不会发生。
• 若两个事务读取总和后还会修改关联账户的余额：Serializable的冲突检测机制会判定两个事务存在序列化冲突，会主动回滚其中一个事务，返回序列化冲突报错，此时需要重试被回滚的事务才能正常完成操作。这是Serializable为了保证数据一致性的正常拦截行为，符合隔离级别设计预期。

内容的提问来源于stack exchange，提问作者Kristina