PostgreSQL事务隔离级别与MVCC快照一致性实战解析

PostgreSQL MVCC机制与事务隔离的关系

PostgreSQL使用多版本并发控制（MVCC）实现事务隔离，每行数据的不同版本通过xmin和xmax系统列标识其可见性范围。当一个事务读取数据时，它看到的是该事务开始时刻的快照——即所有在快照时刻已提交的事务结果。这种快照读（Snapshot Read）机制是Read Committed和Repeatable Read两个隔离级别的基础。

PostgreSQL的Repeatable Read在SQL标准中对应Snapshot Isolation，与MySQL的Repeatable Read（基于Gap Lock实现）行为差异显著。PostgreSQL的Repeatable Read不会出现幻读，但可能出现写偏差（Write Skew），这是SN隔离级别的固有特性。

四种隔离级别的行为差异

PostgreSQL支持三种有效隔离级别（Read Uncommitted被当作Read Committed处理）：

-- 查看当前隔离级别
SHOW transaction_isolation;

-- 设置事务隔离级别
BEGIN ISOLATION LEVEL READ COMMITTED;
BEGIN ISOLATION LEVEL REPEATABLE READ;
BEGIN ISOLATION LEVEL SERIALIZABLE;

三种级别的核心区别：

Read Committed：每条SQL语句执行前获取新快照。同一事务内两次相同的SELECT可能返回不同结果（其他事务已提交的修改可见）。这是PostgreSQL默认级别。

Repeatable Read：事务开始时获取快照，整个事务内快照不变。同一事务内两次相同的SELECT一定返回相同结果。但如果两个并发事务修改同一行，后提交的事务会收到序列化失败错误。

Serializable：在Repeatable Read基础上增加谓词锁检测，防止写偏差。通过SSI（Serializable Snapshot Isolation）算法追踪读写依赖，当检测到危险结构时回滚其中一个事务。

并发场景实战：脏读、不可重复读与幻读

通过实际操作验证不同隔离级别的行为：

-- 会话A
BEGIN ISOLATION LEVEL READ COMMITTED;
SELECT balance FROM accounts WHERE id = 1;  -- 返回1000

-- 会话B（并发执行）
UPDATE accounts SET balance = 800 WHERE id = 1;
COMMIT;

-- 会话A再次查询
SELECT balance FROM accounts WHERE id = 1;  -- Read Committed返回800
                                       -- Repeatable Read返回1000

幻读场景验证：

-- 会话A
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT COUNT(*) FROM orders WHERE amount > 1000;  -- 返回5

-- 会话B
INSERT INTO orders (amount) VALUES (2000);
COMMIT;

-- 会话A再次查询
SELECT COUNT(*) FROM orders WHERE amount > 1000;  -- 仍然返回5（无幻读）

PostgreSQL的Repeatable Read在快照隔离下天然防止幻读，因为整个事务看到的数据版本集合是固定的。新插入的行对快照不可见。

写偏差问题与Serializable级别解决

写偏差是Repeatable Read无法防止的异常：

-- 场景：两个柜员同时取款，账户余额必须大于等于0
-- 会话A
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT balance FROM accounts WHERE id = 1;  -- 返回1000

-- 会话B（并发）
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT balance FROM accounts WHERE id = 1;  -- 返回1000

-- 会话A
UPDATE accounts SET balance = balance - 800 WHERE id = 1;
COMMIT;  -- 成功，余额200

-- 会话B
UPDATE accounts SET balance = balance - 800 WHERE id = 1;
COMMIT;  -- 成功，余额-600！违反业务约束

两个事务都读取到余额1000，各自判断足够后扣款，但汇总结果违反了余额大于等于0的约束。Serializable级别可以检测并阻止这种情况：

-- 使用Serializable重演
-- 会话B的COMMIT将被回滚并报错：
-- ERROR: could not serialize access due to read/write dependencies

MVCC快照与行版本可见性判断

理解MVCC快照对排查并发问题至关重要。每个行版本包含xmin（创建该版本的事务ID）和xmax（删除该版本的事务ID，未删除时为0）：

-- 查看行版本信息
SELECT xmin, xmax, * FROM accounts WHERE id = 1;

-- 查看当前活跃事务快照
SELECT txid_current_snapshot();

-- 判断行版本对某事务是否可见
SELECT txid_visible_in_snapshot(xmin, txid_current_snapshot()) AS visible,
       xmin, xmax, *
FROM accounts;

行版本可见性判断规则：xmin对应的事务必须已提交且在快照之前，xmax对应的事务必须未提交或在快照之后。PostgreSQL内部通过CLOG（Commit Log）和快照的xmin/xmax范围快速判断。

隔离级别选择与生产建议

隔离级别选择不是越高越好——Serializable的序列化失败率在高并发写场景下可能很高，需要频繁重试事务。生产环境的建议：

1. 默认Read Committed适用于大多数OLTP场景，简单直接，冲突少。
2. 报表查询和需要一致视图的批处理使用Repeatable Read，避免读期间数据漂移。
3. 有严格业务约束（如余额不能为负、库存不能超卖）的场景使用Serializable，配合应用层重试逻辑。
4. Serializable环境下的应用代码必须捕获序列化失败错误并自动重试整个事务，典型重试3次。

-- 应用层重试模板（伪代码）
-- max_retries = 3
-- for i in range(max_retries):
--     BEGIN ISOLATION LEVEL SERIALIZABLE;
--     result = execute_business_logic();
--     try:
--         COMMIT;
--         return result;
--     except SerializationError:
--         ROLLBACK;
--         continue
-- raise Error("max retries exceeded")

监控指标方面，关注pg_stat_database的deadlocks和conflicts计数器。Serializable场景下deadlocks增多通常意味着并发冲突热点，需要优化事务粒度或引入显式行锁（SELECT FOR UPDATE）减少序列化失败率。