对于 READ COMMITTED 隔离，重复的主键是否很明显？答案

【问题标题】：Can duplicate primary keys be apparent for READ COMMITTED isolation?对于 READ COMMITTED 隔离，重复的主键是否很明显？
【发布时间】：2016-02-18 02:14:21
【问题描述】：

我有一个带有主键的表，它由唯一性约束支持。因此，具有 SERIALIZABLE 隔离的查询永远不应返回具有相同主键的两行。但是对于具有 READ COMMITTED 隔离的查询也是如此吗？什么是最宽松的隔离级别，不可能出现明显的重复主键？

【问题讨论】：

标签： sql isolation-level

【解决方案1】：

明显重复的最宽松的隔离级别是什么主键是不可能的？

REPEATABLE READ 或 READ COMMITTED SNAPSHOT

在 SQL Server 中，扫描READ COMMITTED（锁定）绝对有可能读取一行两次。

在此隔离级别，行锁在读取数据后立即释放，而不是在语句或事务结束时释放。

因此，如果在初始读取后更新了键，则按键顺序读取索引的扫描可能会再次遇到同一行，将其移动到索引的后面。为了在实践中观察重复的主键，被扫描的索引可能需要位于与 PK 本身不同的键列上。

如果尚未读取的数据在索引中向前移动到已扫描的部分，REPEATABLE READ 可能会丢失行，但这不会允许出现明显重复主键的现象。

【讨论】：

【解决方案2】：

在 OracleDB 上，就您的 PK 不可延迟和延迟而言，您不能违反它：即使在支持的最低“READ COMMITTED”级别（ANSI/ISO 级别 1）中，在同一行上运行的不同会话也会发生在行锁争用。因此，第二个会话的 DML 将一直等待，直到第一个释放锁 - 通过提交或回滚 - 然后它会被即时验证，如果违反 PK 它将失败。

【讨论】：

要明确的是，您实际上也不能在 SQL Server 中违反它。问题是关于明显的违规行为。例如其中 SELECT * FROM T 多次返回相同的 PK 值作为结果，即使表本身没有重复项。
在 OracleDB 上，游标在打开时被冻结，因此无论您设置什么隔离级别，都无法读取重复的 PK，除非 PK 被延迟并且违规是由于同一会话中未提交的数据造成的。