在 PostgreSQL 中混合隔离级别答案

【问题标题】：Mixing isolation levels in PostgreSQL在 PostgreSQL 中混合隔离级别
【发布时间】：2014-07-11 09:22:41
【问题描述】：

如果任何其他会话使用例如 SERIALIZABLE 事务，这是否重要？ autocommit 还是 READ COMMITED 隔离级别？

换句话说，当从多个进程/线程（或其他需要注意的事项）访问数据库时，混合隔离级别（和自动提交）是否有任何危险？

请注意，我知道“普通”问题，例如 SERIALIZABLE 事务要求重试等。我要求的是混合不同隔离级别时可能发生的任何不明显的问题。

编辑：

一致使用可序列化事务可以简化开发。保证任何一组并发可序列化事务将具有与一次运行一个相同的效果，这意味着如果您可以证明单个事务，如所写，在以下情况下会做正确的事情独立运行，您可以确信它会在任何可序列化事务的组合中做正确的事情，即使没有任何关于其他事务可能做什么的信息。

这可能表明混合隔离级别不是一个好主意。另一方面，它只是说一致使用 SERIALIZABLE 级别是好的，而不是混合隔离级别是不好的。

【问题讨论】：

【解决方案1】：

在 SERIALIZABLE 之外的事务隔离级别上运行的任何事务都不会受到 SSI 的影响。如果你想通过 SSI 强制执行业务规则，所有事务都应该在 SERIALIZABLE 事务隔离级别上运行，并且应该设置为默认值。

因此，在混合隔离级别时，SERIALIZABLE 保证不会成立。

【讨论】：

【解决方案2】：

SERIALIZABLE

当前事务的所有语句只能看到在此事务中执行第一个查询或数据修改语句之前提交的行。如果在并发可序列化事务中的读写模式会造成这些事务的任何串行（一次一个）执行都不会发生的情况，则其中一个将被滚动返回一个 serialization_failure 错误。

这意味着，SERIALIZABLE 事务仅在针对另一个 SERIALIZABLE 事务运行时表现不同。如果它们针对非SERIALIZABLE 事务运行，它们应该像REPEATABLE READ 事务一样运行。这表明，混合这些事务隔离级别是完全安全的。

【讨论】：

我看不出你的结论与你的报价有什么关系。我在DBA讨论过这个问题，发现手册中的重要细节是Serializable指隔离级别和serializable指调度的区别。理解这一点，就可以得出结论，Serializable 事务在 ANSI 标准中明确定义是安全的。
这听起来很危险，不安全。这意味着如果并发的不可序列化事务干扰，您的可序列化事务可能会做出错误的假设。假设您开始一个可序列化的 xact A 并执行一些“INSERT ... WHERE NOT EXISTS”，然后一个不可序列化的 xact B 插入与 WHERE 子句匹配的行并提交，A 仍将提交，现在也许您的应用程序工作人员使用 xact A 做错了什么。