PostgreSQL：如何针对单表或单次读取放宽事务隔离级别保障？

当然可以！针对你这种不常变更的配置表场景，有几种实用的方法能让你在SERIALIZABLE事务中放宽对global_flags的读取一致性要求，从而减少序列化失败的概率。

方案1：将配置读取放在独立的低隔离级别事务中 #

既然global_flags不常变更，你可以先在一个READ COMMITTED隔离级别的独立事务中读取配置值，再启动你的SERIALIZABLE主事务。这样读取配置的操作不会参与主事务的SERIALIZABLE一致性检查，也就不会因为配置表的修改导致主事务触发序列化失败。

示例代码：

// 先单独读取配置，用READ COMMITTED隔离级别
const batchSizeResult = await sqlAsync(`
  BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
  SELECT value FROM global_flags WHERE name = 'batch_size';
  COMMIT;
`);
const batchSize = batchSizeResult.rows[0].value;

// 启动主SERIALIZABLE事务
await sqlAsync(`BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE`);
// ... 使用batchSize执行后续业务操作 ...
await sqlAsync('COMMIT');

优点：实现简单，不需要修改现有主事务的逻辑；缺点：如果在读取配置和主事务执行之间，配置被修改了，主事务会使用旧的配置值——但因为你提到配置不常变更，这个风险通常是可接受的。

方案2：使用时间点快照读取配置表 #

PostgreSQL支持基于时间点的快照读取（需要提前开启track_commit_timestamp参数），你可以在SERIALIZABLE事务中直接读取global_flags的历史快照数据。这样即使配置表被修改，当前事务读取的是修改前的历史数据，不会触发SERIALIZABLE的一致性检查失败。

示例代码：

await sqlAsync(`BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE`);
// 读取1分钟前的快照数据，可根据实际情况调整时间范围
const batchSizeResult = await sqlAsync(`
  SELECT value FROM global_flags 
  WHERE name = 'batch_size' 
  AS OF SYSTEM TIME '-1 minute';
`);
const batchSize = batchSizeResult.rows[0].value;
// ... 执行后续业务操作 ...
await sqlAsync('COMMIT');

优点：不需要拆分事务，保持代码连贯性；缺点：需要提前在PostgreSQL配置中开启track_commit_timestamp，并且你需要接受读取到稍旧的配置值。

为什么这些方案能减少序列化失败？ #

SERIALIZABLE隔离级别会检查所有读写操作的序列化顺序，当global_flags被修改时，所有在修改前后读取该表的SERIALIZABLE事务都可能被判定为无法按顺序序列化，从而抛出serialization failure错误。通过上述方案，我们让配置表的读取操作脱离了SERIALIZABLE的严格一致性检查，自然就避免了这类由配置表修改引发的失败。

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