PostgreSQL与MySQL在事务隔离级别实现上有何关键差异？

Question

**常见技术问题：** 为什么在MySQL（InnoDB）中设置`REPEATABLE READ`隔离级别能避免不可重复读，而PostgreSQL的`REPEATABLE READ`却能完全避免幻读，且语义上更接近SQL标准的`SERIALIZABLE`？两者同名隔离级别行为差异巨大，是否意味着MySQL的`REPEATABLE READ`名不副实？当应用从MySQL迁移到PostgreSQL时，仅保持相同隔离级别配置，为何会出现并发逻辑异常（如丢失更新或意外序列化失败）？其根本原因是否在于MySQL依赖“间隙锁（Gap Lock）”实现可重复读，而PostgreSQL基于MVCC快照+SSI（可串行化快照隔离）机制，在`REPEATABLE READ`下即提供真正可串行化语义？这种底层实现差异如何影响锁竞争、死锁概率及只读事务性能？

Answer 1

```html

一、概念辨析：SQL标准 vs. 实现语义的“同名异义”现象

SQL-92标准定义了四个隔离级别，其中REPEATABLE READ要求：事务内多次读取同一行数据结果一致（防不可重复读），且禁止幻读（即新插入/删除行不应影响已存在谓词结果集）。但MySQL（InnoDB）与PostgreSQL对这一名称的实现存在根本性分叉：

• MySQL RR：通过多版本快照 + 行锁 + 间隙锁（Gap Lock）阻止幻读——但仅限于当前读（SELECT ... FOR UPDATE等），普通快照读仍可能因未加锁而“看不见”新行，故不完全满足标准幻读定义；
• PostgreSQL RR：自9.1起默认采用SSI（Serializable Snapshot Isolation）算法，在REPEATABLE READ级别下即提供真正可串行化语义，能检测并阻断所有导致异常的并发模式（包括写偏斜、幻读、丢失更新）。

二、底层机制对比：锁模型 vs. MVCC+冲突检测

维度	MySQL (InnoDB)	PostgreSQL
核心机制	悲观并发控制（PCC）+ Gap Lock + Next-Key Lock	乐观并发控制（OCC）+ MVCC快照 + SSI运行时依赖图检测
幻读防护	仅对当前读有效；普通SELECT不加锁，可能漏见新行	所有读操作均基于事务开始时刻快照，且SSI自动拦截幻读风险事务
丢失更新	需显式加锁（如SELECT ... FOR UPDATE）或应用层CAS	SSI自动检测并中止造成写偏斜的事务（返回SerializationFailure）

三、迁移陷阱：为何“相同配置”反而引发并发异常？

当应用从MySQL迁移到PostgreSQL并保留SET TRANSACTION ISOLATION LEVEL REPEATABLE READ时，常出现两类典型异常：

1. 意外序列化失败：PostgreSQL在RR下主动拒绝不可串行化调度，抛出ERROR: could not serialize access due to read/write dependencies；而MySQL RR对此类场景静默允许，导致逻辑错误潜伏；
2. 丢失更新加剧：MySQL中若未使用FOR UPDATE，两个事务并发更新同一行将发生后写覆盖；PostgreSQL虽有MVCC避免脏写，但SSI会检测到写偏斜（如A查余额→B查余额→A扣款→B扣款），强制回滚其一。

四、性能影响分析：锁竞争、死锁与只读事务

graph LR
  A[MySQL RR] --> B[高锁竞争]
  A --> C[间隙锁扩大锁定范围]
  A --> D[死锁概率显著上升]
  A --> E[只读事务无锁开销，极轻量]
  F[PostgreSQL RR] --> G[零行级锁，无锁等待]
  F --> H[SSI仅在提交阶段检测冲突]
  F --> I[只读事务完全无开销，快照复用率高]
  F --> J[写密集场景下因重试导致延迟波动]

五、工程实践建议：跨数据库迁移的适配策略

• 隔离级别映射表：
  • MySQL REPEATABLE READ ≈ PostgreSQL READ COMMITTED（行为兼容性最高）
  • 若需强一致性，MySQL应升至SERIALIZABLE（实为表级锁），PostgreSQL保持REPEATABLE READ即可
• 代码改造重点：
  • 捕获PostgreSQL的serialization_failure异常，实现指数退避重试逻辑；
  • 移除MySQL风格的“先查后更”裸SQL，改用UPDATE ... WHERE version = ?或INSERT ... ON CONFLICT；
  • 审计所有隐式快照读场景，确认是否需升级为SELECT ... FOR SHARE显式加锁。

六、本质结论：命名失准源于设计哲学差异

MySQL的REPEATABLE READ并非“名不副实”，而是明确选择了工程实用性优先：以间隙锁换取高吞吐下的基本一致性，牺牲标准符合性换取低延迟。PostgreSQL则坚持理论正确性优先，用SSI在RR级别达成SQL标准中SERIALIZABLE的实质能力。二者没有优劣之分，只有适用边界的差异——这正是数据库内核二十年演进中“理论派”与“实用派”持续博弈的缩影。

```