MVCC在PostgreSQL中的实践

PostgreSQL 中 MVCC 的实践指南

一 核心原理与关键概念

• 多版本存储：每次对行进行INSERT/UPDATE/DELETE都会产生新版本，旧版本保留一段时间；读操作依据事务快照选择可见版本，实现读不阻塞写、写不阻塞读。
• 隐藏系统列：每行包含xmin、xmax、cmin、cmax。其中xmin为插入该行的事务 ID，xmax为删除或更新该行的事务 ID（为0表示未被删除）；cmin/cmax是事务内的命令序号，用于命令级别的可见性判断。
• 事务快照：事务开始时获取当前活跃事务集合，形成快照用于可见性计算；快照常用表示法为xmin:xmax:xip_list（最早仍活跃事务、下一个将分配事务、活跃事务列表）。
• 隔离级别：PostgreSQL 不实现脏读，默认READ COMMITTED；REPEATABLE READ在 PG 中更强，通常可防止幻读；SERIALIZABLE提供可串行化保证。
• 存储与版本链：行头包含t_ctid指向下一个版本（更新后指向新元组），形成版本链供可见性判断与定位。

二 典型并发场景与 SQL 实践

• 场景一 读已提交下的“读到他人已提交”
  在READ COMMITTED下，同一事务内的每条语句都基于该语句执行时的已提交数据；因此期间他人提交会立刻被看到。
  示例：

  BEGIN;
  SELECT balance FROM account WHERE id = 1; -- 假设返回 100
  -- 其他事务在此期间 UPDATE 并提交为 200
  SELECT balance FROM account WHERE id = 1; -- 现在返回 200
  COMMIT;
  

• 场景二 可重复读下的“快照一致性”
  在REPEATABLE READ下，事务基于启动时快照读取，期间他人提交的数据不可见，通常也不会出现幻读。
  示例：

  BEGIN ISOLATION LEVEL REPEATABLE READ;
  SELECT * FROM my_table WHERE id = 1; -- 假设 xmin=100
  -- 其他事务 UPDATE 并提交（新版本 xmin=200）
  SELECT * FROM my_table WHERE id = 1; -- 仍看到 xmin=100 的旧版本
  COMMIT;
  

• 场景三 显式加锁避免写写冲突
  在READ COMMITTED下，用SELECT … FOR UPDATE/ FOR SHARE锁定关键行，避免竞态。
  示例：

  BEGIN;
  SELECT id FROM account WHERE user_id = 1 FOR UPDATE;
  UPDATE account SET balance = balance - 100 WHERE user_id = 1 AND balance >= 100;
  COMMIT;
  

• 场景四 序列化隔离与冲突重试
  在SERIALIZABLE下，冲突会抛出序列化错误（常见错误码40001），需捕获并重试。
  示例（Go + GORM）：

  for {
      err := db.Transaction(func(tx *gorm.DB) error {
          var acc Account
          tx.Clauses(clause.Locking{Strength: "UPDATE"}).
              Where("user_id = ?", uid).First(&acc)
          if acc.Balance < 100 { return errors.New("insufficient") }
          return tx.Model(&acc).Update("balance", acc.Balance-100).Error
      })
      if err == nil { break }
      if pgErr, ok := err.(pgdriver.Error); ok && pgErr.Code == "40001" {
          continue // 重试
      }
      return err
  }
  

  实践要点：优先使用READ COMMITTED；需要一致性读时用REPEATABLE READ；仅在强一致且冲突可控时用SERIALIZABLE；用显式锁替代盲目提升隔离级别。

三 维护与观测要点

• 清理过期版本与防回卷：MVCC 会保留旧版本，需依赖VACUUM/autovacuum回收；长期不清理会导致表膨胀与事务 ID 回卷风险。
  常用命令：

  VACUUM [FULL] [ANALYZE] [VERBOSE] table_name;
  

  建议保持autovacuum = on，并根据负载调整阈值与成本参数。
• 观测膨胀与长事务：

  -- 查看死元组
  SELECT schemaname, relname, n_dead_tup
  FROM pg_stat_all_tables
  WHERE n_dead_tup > 0;
  
  -- 查看当前事务与快照
  SELECT txid_current(), txid_current_snapshot();
  
  -- 监控活动与锁
  SELECT * FROM pg_stat_activity;
  SELECT * FROM pg_locks;
  

• 谨慎使用 VACUUM FULL：VACUUM FULL会重建表并获取表级锁，可能影响在线业务，建议在维护窗口使用。
• 深入排查：安装pageinspect扩展可观察页面与元组细节，辅助定位版本链与可见性问题。

四 常见误区与优化建议

• 误区一 过度使用SERIALIZABLE
  导致冲突与回滚增多，性能下降；优先用READ COMMITTED + 显式锁或业务层冲突消解。
• 误区二 忽略长事务
  长事务会扩大快照范围、延迟VACUUM回收，放大膨胀与回卷风险；尽量缩短事务、及时提交。
• 误区三 用隔离级别替代唯一性/业务约束
  唯一性需依赖唯一索引等约束，隔离级别无法替代数据完整性机制。
• 优化建议
  • 设计上优先短事务、尽早提交；热点行访问用FOR UPDATE串行化关键区段。
  • 合理设置autovacuum成本参数与阈值，避免“清理不及”与“清理过度”。
  • 对高更新表，结合表分区、合理索引与统计信息，降低版本扫描成本。