PostgreSQL支持读已提交、可重复读和串行化三种事务隔离级别，分别适用于不同并发场景；读已提交为默认级别，允许非可重复读和幻读，SELECT不加锁，写操作加行级排他锁；可重复读通过快照避免不可重复读和幻读，依赖MVCC和写冲突检测，可能因冲突失败；串行化基于SSI技术防止串行化异常，需重试事务以保证强一致性；隔离级别越高，一致性越强但性能开销越大，应用需根据需求权衡选择。
PostgreSQL 的事务隔离级别决定了事务之间如何相互影响，尤其是在并发访问相同数据时的可见性和锁行为。PostgreSQL 支持三种标准隔离级别：读已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。每种级别在锁机制和并发控制上表现不同，直接影响应用的性能与一致性。
1. 读已提交（Read Committed）
这是 PostgreSQL 的默认隔离级别，适用于大多数常规业务场景。
说明：- 一个事务中每次 SELECT 查询都会看到在该查询开始前已提交的数据。
- 同一事务内的多次查询可能看到不同的结果（非可重复读）。
- 写操作（UPDATE、DELETE）会获取行级排他锁，防止其他事务修改同一行。
- SELECT 不加共享锁（除非显式使用 FOR SHARE/UPDATE）。
- UPDATE 和 DELETE 在匹配的行上加行级排他锁（Exclusive Lock），并持有到事务结束。
- INSERT 不会对已有行加锁，但可能触发唯一约束检查时产生锁竞争。
- 可能发生“幻读”（Phantom Read），即两次执行相同条件的查询，返回不同数量的行。
2. 可重复读（Repeatable Read）
该级别通过快照机制保证事务内读取的一致性，避免了不可重复读和幻读。
说明：
- 事务启动时建立一个快照，整个事务期间都基于这个快照读取数据。
- 即使其他事务提交了更改，当前事务也看不到这些变化。
- 普通 SELECT 仍不加锁，依赖 MVCC 实现一致性。
- UPDATE 和 DELETE 会尝试锁定目标行；如果发现目标行已被修改（由其他事务提交），则事务会失败并报错“不能序列化访问”，提示存在冲突。
- 系统通过检测写-写冲突来维护可重复性，而不是长时间持有锁。
- 虽然称为“可重复读”，但在 PostgreSQL 中实际行为接近“快照隔离”（Snapshot Isolation）。
3. 串行化（Serializable）
最高隔离级别，确保事务并发执行的效果等价于串行执行。
说明：- 基于可重复读的快照机制，进一步引入“串行化冲突检测”机制。
- PostgreSQL 使用 SSI（Serializable Snapshot Isolation）技术，在运行时分析事务依赖图，预防危险结构。
- 读操作不加传统锁，仍依赖 MVCC 快照。
- 系统后台跟踪读-写和写-写依赖关系。
- 当检测到可能导致串行化异常的情况时，会选择一个事务回滚，并提示错误：“could not serialize access due to concurrent update”。
- 开发者需捕获此类异常并重试事务。
- 没有显式的表锁或行锁用于阻塞读，而是通过逻辑冲突判断实现隔离。
隔离级别对比总结
| 特性 | 读已提交 | 可重复读 | 串行化 |
|---|---|---|---|
| 是否允许脏读 | 否 | 否 | 否 |
| 是否允许不可重复读 | 是 | 否 | 否 |
| 是否允许幻读 | 是 | 否 | 否 |
| SELECT 是否加锁 | 否（除非显式指定） | 否 | 否 |
| UPDATE/DELETE 锁类型 | 行级排他锁 | 行级锁 + 冲突检测 | 行级锁 + SSI 检测 |
| 自动回滚可能性 | 无 | 有（写冲突） | 有（串行化异常） |
| 适用场景 | 一般Web应用、高并发读写 | 需要一致快照的报表 | 强一致性要求金融系统 |
基本上就这些。选择合适的隔离级别要权衡一致性需求与性能开销。多数情况下，默认的“读已提交”足够用；若需避免幻读且能处理重试逻辑，“串行化”是最安全的选择。理解各级别的锁与MVCC协作方式，有助于设计更健壮的数据库交互逻辑。
