哪些隔离级别会导致序列化失败？

Question

下面来自维基百科的引用（这里）说这READ COMMITTED不会导致序列化失败！你能解释一下原因吗？哪些隔离级别会导致序列化失败？

在多版本并发控制下，在 SERIALIZABLE 隔离级别，两个 SELECT 查询都会看到在事务 1 开始时拍摄的数据库快照。因此，它们返回相同的数据。但是，如果随后事务 2 也尝试更新该行，则会发生序列化失败并且事务 1 将被迫回滚。

在 READ COMMITTED 隔离级别，每个查询都会看到在每个查询开始时拍摄的数据库快照。因此，他们每个人都会看到更新行的不同数据。在这种模式下不可能出现序列化失败（因为没有承诺可序列化），并且事务 1 将不必重试。

Answer 1

对此，不可能给出一个简短的答案。

我建议你从这里开始阅读：

• 在放弃 ACID 并扔掉你的 CAP 之前请三思，
  按照链接，尤其是jepsen.io

• 开发人员对事务的不了解会伤害他们！

• Martin Kleppmann 对隔离级别的看法（在第二个链接中引用 - 以及他的解释）

• 推荐进一步阅读：Kleppmann 的书（我已购买）受到高度评价！在 1525 条评论中，94% 的评价为 4 (8%) 或 5 (86%) 星 - 这是我见过的最好的！

如果您可以阅读并掌握所有这些材料（以及其中的链接——这本书是锦上添花，但并非只是回答这个问题所必需的），那么您将很好地了解事务和隔离级别！

编辑：

响应 OP 的评论 - by serialization failure，我相信 wiki 的作者（在这里- 如果可能，请在将来引用参考文献）的意思是，在第一种情况下，由于隔离级别，T1 将失败被设置为SERIALIZABLE- 而在第二种情况下，级别READ COMMITTED将意味着 T1 不会失败。

实现交易的重要思想SERIALIZABLE是（从这里）：

如果事务调度的结果（例如，结果数据库状态）等于其串行执行的事务的结果，即在时间上没有重叠，则事务调度是可串行化的。

因此，T1 将失败，因为由于 T2 的修改，它的整个数据视图不能在整个事务时间（即所有查询）上保持一致。

我发现（这让我困惑了一段时间，直到我弄明白了）查询和事务之间存在巨大差异——查询可能是也可能不是事务的适当子集。在大多数现代 RDBMS 上，如果您没有明确指定 a或 an ，则默认值为：BEGIN TRANSACTIONisolation level

• a) 在幕后自动为您启动交易，并且，

• b) 该事务是读提交的——这通常无关紧要，因为它是一个查询。

当您开始运行多查询事务时，区别真的变得很重要 - 那时小麦从谷壳中分拣出来，开发人员必须重新了解服务器中发生的事情。事务隔离级别

与 IT 和数据库中的所有事物一样，特别是存在平衡、权衡和妥协。您可能会问，为什么SERIALIZABLE不是默认值和/或不总是指定的？答案很简单：性能——这是你的权衡！

我现在敦促您阅读我提供的参考资料 - 在您选择的服务器（或多个服务器，如果您真的想进入它！）上使用两个 CLI 窗口进行一些实验，运行一些引用的代码！